Adrian Chapela wrote:
I send you this mail directly because the email list rejects my mail.

Tom Eastep escribió:
Adrian Chapela wrote:

For example, 192.168.19.5 must are going by auna ISP but I am seeing packets on mundor Why ?

If you don't send the information we ask for, you are just wasting your time and ours.

Excuse me, I will send you attach of  shorewall dump.
The problem is:
All is working but I can't define marks to do tcrules well. All of my traffic is going out by one ISP.

From the dump:

Chain tcpre (3 references)
pkts bytes target prot opt in out source destination 67 3172 MARK all -- * * 192.168.18.0/24 !192.168.0.0/16 MARK set 0x1 263 20300 MARK all -- * * 192.168.19.0/24 !192.168.0.0/16 MARK set 0x1 0 0 MARK all -- * * 192.168.19.5 !192.168.0.0/16 MARK set 0x2 0 0 MARK all -- * * 192.168.19.42 !192.168.0.0/16 MARK set 0x2 0 0 MARK all -- * * 192.168.19.201 !192.168.0.0/16 MARK set 0x2 0 0 MARK all -- * * 192.168.19.203 !192.168.0.0/16 MARK set 0x2 1 60 MARK all -- * * 192.168.19.205 !192.168.0.0/16 MARK set 0x2 69 6100 MARK all -- * * 192.168.19.144 !192.168.0.0/16 MARK set 0x2 <========== 0 0 MARK all -- * * 192.168.19.22 0.0.0.0/0 MARK set 0x2

So 69 connections have been marked to go out of aunu.


Another question could be, Why now I need to use balance and until yesterday I could use "track" option in provider?

From the dump:

/proc

   /proc/sys/net/ipv4/conf/auna/proxy_arp = 0
   /proc/sys/net/ipv4/conf/auna/arp_filter = 0
   /proc/sys/net/ipv4/conf/auna/arp_ignore = 0
   /proc/sys/net/ipv4/conf/auna/rp_filter = 1       <=====
   /proc/sys/net/ipv4/conf/auna/log_martians = 0    <=====

This explains why the 'aunu' provider was not working without 'balance'. Packets arriving from that provider were being silently dropped as 'Martians'. I suspect that the rp_filter = 1 setting occurred yesterday which is why it suddenly stopped working.

Do you have 'route_filter' specified on the aunu interface in /etc/shorewall/interfaces?

Hint: You should NEVER set the 'route_filter' option without the 'log_martians' option (in Shorewall 4.2, log_martians will be on by default).

And there _IS_ (or has been) traffic going through aunu:

4: mundor: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:0a:5e:64:66:e6 brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast
    41870838   227929   0       0       0       0
    TX: bytes  packets  errors  dropped carrier collsns
    64122751   140429   0       0       0       0
5: auna: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:0a:5e:64:67:3a brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast
    1001062    8507     0       0       0       0  <===========
    TX: bytes  packets  errors  dropped carrier collsns
    1579949    5807     0       0       0       0  <===========

These could be because of the incoming DNAT rules though as there are quite a few active connections through auna.

Sorry that I don't have any more time to look at this now as I am already late for work.

-Tom
--
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ [EMAIL PROTECTED]
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key

Attachment: signature.asc
Description: OpenPGP digital signature

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Reply via email to