Tom Eastep wrote: > Brian J. Murrell wrote: >> Tom Eastep <teastep <at> shorewall.net> writes: >>> If it were not having any effect, the SOURCE IP would be 10.75.22.101, >>> right? >> Ahhh. Yes, of course, you are right. So some SNAT/Masq is happening, just >> for >> the wrong outgoing interface. >> >>> It's not clear to me what's happening from what you have written. >> Sorry. It really is simply a case of using a route_rules entry to force >> traffic from a given IP (10.75.22.101) out through what is normally not the >> "default"/preferred interface (which is provider CGCO), which is working. >> But >> that the source address of what is normally the preferred/default interface >> (CGCO's 7.1.7.2) is being masqued to the packets instead of the source >> address >> of the interface (IGS0 being forced by the route_rules entry. >> >> What I don't understand is why given the following nat table rules: >> >> Chain POSTROUTING (policy ACCEPT 782 packets, 47801 bytes) >> pkts bytes target prot opt in out source destination >> 1 1400 ppp0_masq all -- * ppp0 0.0.0.0/0 0.0.0.0/0 >> 2581 201K eth0.1_masq all -- * eth0.1 0.0.0.0/0 0.0.0.0/0 >> >> Chain ppp0_masq (1 references) >> pkts bytes target prot opt in out source destination >> 1 1400 SNAT all -- * * !6.1.3.4 0.0.0.0/0 to:6.1.3.4 >> >> Chain eth0.1_masq (1 references) >> pkts bytes target prot opt in out source destination >> 5344 414K MASQUERADE all -- * * 0.0.0.0/0 0.0.0.0/0 >> >> is the eth0.1 masqing being applied to packets which are routed to the IGS >> (on >> ppp0) provider with the route rule: >> >> 1002: from 10.75.22.101 lookup IGS >> >> and associated routing table: >> >> Table IGS: >> >> 10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1 >> 192.168.200.1 dev ppp0 scope link src 66.11.173.224 >> 10.10.0.0/24 via 10.75.22.1 dev br-lan proto zebra metric 20 equalize >> 10.8.0.0/24 via 10.8.0.2 dev tun0 >> 192.168.0.0/24 via 10.75.22.5 dev br-lan proto zebra metric 20 equalize >> 10.75.22.0/24 dev br-lan proto kernel scope link src 10.75.22.254 >> 10.75.23.0/24 via 10.8.0.2 dev tun0 >> 192.168.122.0/24 via 10.75.22.151 dev br-lan proto zebra metric 20 >> equalize >> 169.254.0.0/16 via 10.75.22.5 dev br-lan proto zebra metric 20 equalize >> default via 192.168.200.1 dev ppp0 src 6.1.3.4 >> >> Doesn't the above set the outgoing interface to ppp0 before POSTROUTING is >> applied in the iptables "nat" table? > > I guess I need to be more explicit; I don't understand it either because > from what you have described, either your kernel is badly broken or you > are leaving out pertinent information (hint -- 'shorewall dump').
What you are seeing on ppp0 are response packets that are part of connections initiated via DNAT on eth0.1. Here's a connection from the dump you sent me privately: tcp 6 252 ESTABLISHED src=x.y.y.z dst=6.1.3.4 sport=59075 dport=40718 packets=120 bytes=5929 src=10.75.22.101 dst=y.x.y.z sport=40718 dport=59075 packets=170 bytes=10876 [ASSURED] mark=256 use=2 Outgoing packets from that connection are being routed out of ppp0 by your routing rules. Because those packets are not in the NEW connection state, they do not pass through the ppp0_masq chain so their source IP will be 6.1.3.4. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev
_______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
