Hi, I got a problem with iproute and shorewall but I don''t know where the real problem is yet, perhaps someone can shed any light on this one. What we currently do is route all traffic coming from a specific host through our second isp''s nat router. This is done via SNAT on our own router. /etc/shorewall/masq: eth2 $INTERNALHOSTA 192.168.0.142 We now want to route all traffic coming from another host through that link too _but_ only for a specific port, all other traffic is to still flow through ISP1. I added a rule just like the one that is generated by shorewall for the above entry: iptables -t nat -I eth2_masq -p tcp -s InternalhostA --dport 2525 -j SNAT --to-source 192.168.0.142 In the tcrules file I mark all traffic that I want to route through ISP2. /etc/shorewall/tcrules: 1:P $INTERNALHOSTA 0.0.0.0/0 tcp 2525 Then I tell iproute to route everything with that mark to be handled by the table for ISP2: ip rule add pref 1500 table qsc fwmark 1 The qsc table only has a default route via 192.168.0.254. ISP2 | ISP2''s NAT Router (192.168.0.254) | eth2 | 192.168.0.142 ISP1 --eth0---- Router --eth1-- |--------- InternalhostA all traffic works! |--------- InternalhostB port2525 doesn''t :( This seems to work to a point, traffic goes out via eth2 and ACKs come back but they never make it to eth1 and InternalhostB :( Nothing in the firewall logs either and the connection tracking record in /proc/net/ip_conntrack looks ok doesn''t it? tcp 6 59 SYN_RECV src=INTERNALHOSTA dst=80.130.222.48 sport=48664 dport=2525 src=80.130.222.48 dst=192.168.0.142 sport=2525 dport=48664 use=1 Suggestions? Alex
Alexander Gretencord wrote:> > This seems to work to a point, traffic goes out via eth2 and ACKs come back > but they never make it to eth1 and InternalhostB :( Nothing in the firewall > logs either and the connection tracking record in /proc/net/ip_conntrack > looks ok doesn''t it? > > tcp 6 59 SYN_RECV src=INTERNALHOSTA dst=80.130.222.48 sport=48664 dport=2525 > src=80.130.222.48 dst=192.168.0.142 sport=2525 dport=48664 use=1 > > Suggestions?Given that the connection is still in SYN_RECV state, the ACKs coming back from the NATing router aren''t being associated with the above connection. You need to examine them closely to determine why that is so. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Monday 28 June 2004 22:30, Tom Eastep wrote:> Given that the connection is still in SYN_RECV state, the ACKs coming > back from the NATing router aren''t being associated with the above > connection. You need to examine them closely to determine why that is so.Well I''ve looked at a tcpdump capture and the ip_conntrack entry and all the port numbers and IP adresses match. I really don''t know why linux thinks they don''t belong together. What else can I do? What do you mean by "examine closely"? Alex
Alexander Gretencord wrote:> On Monday 28 June 2004 22:30, Tom Eastep wrote: > >>Given that the connection is still in SYN_RECV state, the ACKs coming >>back from the NATing router aren''t being associated with the above >>connection. You need to examine them closely to determine why that is so. > > > Well I''ve looked at a tcpdump capture and the ip_conntrack entry and all the > port numbers and IP adresses match. I really don''t know why linux thinks they > don''t belong together. What else can I do? What do you mean by "examine > closely"?Sorry, I mislead you; the conntrack entry you posted indicates that the SYN,ACK has been received but no ACK from the client has been seen. This agrees with the observed behavior that the SYN,ACK isn''t being passed back to InternalhostB. One thing I noticed about the conntrack entry: tcp 6 59 SYN_RECV src=INTERNALHOSTA dst=80.130.222.48 sport=48664 dport=2525 src=80.130.222.48 dst=192.168.0.142 sport=2525 dport=48664 use=1 Did you mean INTERNALHOSTB rather than INTERNALHOSTA? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Wednesday 30 June 2004 16:07, Tom Eastep wrote:> Sorry, I mislead you; the conntrack entry you posted indicates that the > SYN,ACK has been received but no ACK from the client has been seen. This > agrees with the observed behavior that the SYN,ACK isn''t being passed > back to InternalhostB.Well how would the ACK be coming back when no SYN,ACK has gone out the internal interface :) A tcpdump on eth1 only shows the SYN packet going out but nothing coming back in. What I really don''t get is why this doesnt work as desired when it works with InternalhostA''s traffic? The difficult direction works but not the one that conntracking should handle without a problem? Theres nothing in the shorewall logs either. Does the SNAT entry shorewall generates also generate some other rule I have not found? I even looked at shorewall debug output but could only see the -j SNAT rule.> Did you mean INTERNALHOSTB rather than INTERNALHOSTA?Yes sure, as well as in the tcrules file. Alex
Alexander Gretencord wrote:> On Wednesday 30 June 2004 16:07, Tom Eastep wrote: > >>Sorry, I mislead you; the conntrack entry you posted indicates that the >>SYN,ACK has been received but no ACK from the client has been seen. This >>agrees with the observed behavior that the SYN,ACK isn''t being passed >>back to InternalhostB. > > > Well how would the ACK be coming back when no SYN,ACK has gone out the > internal interface :)Exactly!> A tcpdump on eth1 only shows the SYN packet going out > but nothing coming back in. What I really don''t get is why this doesnt work > as desired when it works with InternalhostA''s traffic?I don''t know.> The difficult > direction works but not the one that conntracking should handle without a > problem? Theres nothing in the shorewall logs either. > > Does the SNAT entry shorewall generates also generate some other rule I have > not found?Each entry in the masq file generates a single SNAT rule.> I even looked at shorewall debug output but could only see the -j > SNAT rule.That''s all there should be. If you can do a controlled test, we might see what''s happening: a) shorewall reset b) Try the connection c) capture "shorewall status" -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net