Vieri Di Paola wrote: > --- Tom Eastep <[EMAIL PROTECTED]> wrote: > >> I would next do the tcpdump >> on eth0 on the bridge >> (make sure the SYN,ACKs are being sent from the >> bridge) then on eth1 on the >> outer firewall. >> >> I see this conntrack entry on the bridge: >> >> tcp 6 35 SYN_RECV src=194.179.55.129 >> dst=10.215.144.7 sport=61911 >> dport=25 packets=1 bytes=52 src=10.215.144.7 >> dst=194.179.55.129 sport=25 >> dport=61911 packets=5 bytes=260 mark=0 use=1 >> >> This indicates that Netfilter connection tracking on >> the bridge is not >> seeing or not recognizing the SYN,ACK response. >> >>> http://213.96.91.201/shorewall/ >> In this dump, I did not see a conntrack entry on the >> bridge as before but >> there is one on the outer firewall. >> >> tcp 6 0 SYN_RECV src=194.179.55.129 >> dst=192.168.100.2 sport=39005 >> dport=25 packets=1 bytes=52 src=10.215.144.7 >> dst=194.179.55.129 sport=25 >> dport=39005 packets=6 bytes=312 mark=2 use=1 >> >> My advice from yesterday still stands >> you need to understand where the responding SYN,ACK >> is being lost. > > I wish I knew how to do that efficiently. Should I > `watch` /proc/net/ip_conntrack on both shorewall > systems and grep the remote host's public IP address > and log the SYN_* states? > I suppose that a "successful" connection would go > through stages SYN_SENT, SYN_RECV, ESTABLISHED on both > shorewall systems?
I think you should run tcpdump on the various interfaces like I suggested. > > What really puzzles me is that this is happening only > with this particular host (at least according to user > feedback), ie. 1 case out of "so many". > The SMTP server doesn't have any extra routes defined on it that is redirecting replies to that client does it? > Anyway, what can be deduced from your two previous > findings related to SYN_RECV that appeared on the > bridge in yesterday's dump and on the gateway in > today's dump? http://iptables-tutorial.frozentux.net/iptables-tutorial.html#TCPCONNECTIONS > Shouldn't SYN_RECV appear on both? (I did notice that > shorewall dump took *a lot* more time to complete on > the bridge so maybe the conntrack entry got removed?) > Might be -- does your bridge have an enormous log? If so, /sbin/shorewall can take a long time wading through the entire log so it can print the last 20 'Shorewall' messages. > I didn't grasp the meaning of the fact that if > SYN_RECV is found on the bridge then that means that > conntrack did not see/recognize the SYN/ACK response. > ( the network is: WORLD --- GATEWAY --- EXTERNAL LAN > --- BRIDGE --- INTERNAL NETWORK WITH SMTP SERVER ) Again, please see http://iptables-tutorial.frozentux.net/iptables-tutorial.html#TCPCONNECTIONS > > Well, I have a lot of TCP/IP homework now (forgive my > ignorance). Thanks for putting me on the right track. > -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
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
