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