I have had to replace an existing setup which has a bunch of IPs Proxy-NAT''ed onto the loc segment. While I do eventually want to move them to their own segment, I have to deal with this for the next few weeks. My problem is that from a loc system I can ping the public IP of a system being proxy-ARP''d but I can''t hit it via HTTP. Nothing is being blocked according to the logs, so I gather this is a lower level problem. The following trace shows the issue (trace is from 10.100.0.23): 4.000988 10.100.0.23 -> 66.46.199.148 ICMP Echo (ping) request 4.002117 66.46.199.148 -> 10.100.0.23 ICMP Echo (ping) reply 18.829470 10.100.0.23 -> 66.46.199.148 HTTP GET / HTTP/1.1 60.260847 10.100.0.23 -> 66.46.199.148 TCP 52834 > http [SYN] Seq=0 Ack=0 Win=65535 Len=0 MSS=1460 WS=0 TSV=2813879722 TSER=0 60.261974 66.46.199.148 -> 10.100.0.23 TCP http > 52834 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=0 TSV=0 TSER=0 60.262073 10.100.0.23 -> 66.46.199.148 TCP 52834 > http [ACK] Seq=1 Ack=1 Win=65535 Len=0 TSV=2813879722 TSER=0 The browser just hangs. I also notice that there is an ICMP Redirect being sent back by the gateway to 10.100.0.23, but I don''t know what that does. Thanks, A.
Adam Sherman wrote:> The browser just hangs.And if I use lynx from another local Linux system, it works!?!?! Lynx from 10.100.0.23, a Mac OS X system, doesn''t. Nor does it work from local Windows XP systems. I am completely confused at this point. Huh? A.
Adam Sherman wrote:> I have had to replace an existing setup which has a bunch of IPs > Proxy-NAT''ed onto the loc segment. While I do eventually want to move > them to their own segment, I have to deal with this for the next few weeks. > > My problem is that from a loc system I can ping the public IP of a > system being proxy-ARP''d but I can''t hit it via HTTP. Nothing is being > blocked according to the logs, so I gather this is a lower level problem. > > The following trace shows the issue (trace is from 10.100.0.23): > > 4.000988 10.100.0.23 -> 66.46.199.148 ICMP Echo (ping) request > 4.002117 66.46.199.148 -> 10.100.0.23 ICMP Echo (ping) reply > 18.829470 10.100.0.23 -> 66.46.199.148 HTTP GET / HTTP/1.1 > 60.260847 10.100.0.23 -> 66.46.199.148 TCP 52834 > http [SYN] Seq=0 > Ack=0 Win=65535 Len=0 MSS=1460 WS=0 TSV=2813879722 TSER=0 > 60.261974 66.46.199.148 -> 10.100.0.23 TCP http > 52834 [SYN, ACK] > Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=0 TSV=0 TSER=0 > 60.262073 10.100.0.23 -> 66.46.199.148 TCP 52834 > http [ACK] Seq=1 > Ack=1 Win=65535 Len=0 TSV=2813879722 TSER=0If you have NEWNOTSYN=No then switch to NEWNOTSYN=Yes. If you have not already, set ''routeback'' on your local interface.> > The browser just hangs. > > I also notice that there is an ICMP Redirect being sent back by the > gateway to 10.100.0.23, but I don''t know what that does.It tells 10.100.0.23 that 66.46.199.148 is connected directly to the LAN. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Tom Eastep wrote:> If you have NEWNOTSYN=No then switch to NEWNOTSYN=Yes. If you have not > already, set ''routeback'' on your local interface.Both the above are already set. NEWNOTSYN=Yes in shorewall.conf and routeback: loc br0 detect tcpflags,routeback>>I also notice that there is an ICMP Redirect being sent back by the >>gateway to 10.100.0.23, but I don''t know what that does. > > It tells 10.100.0.23 that 66.46.199.148 is connected directly to the LAN.Makes sense, thanks. A.
Adam Sherman wrote:> Tom Eastep wrote: > >> If you have NEWNOTSYN=No then switch to NEWNOTSYN=Yes. If you have not >> already, set ''routeback'' on your local interface. > > > Both the above are already set. NEWNOTSYN=Yes in shorewall.conf and > routeback: > > loc br0 detect tcpflags,routeback >Which Shorewall version? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Tom Eastep wrote:>If you have NEWNOTSYN=No then switch to NEWNOTSYN=Yes. If you have not >>>already, set ''routeback'' on your local interface. >> >>Both the above are already set. NEWNOTSYN=Yes in shorewall.conf and >>routeback: >> >>loc br0 detect tcpflags,routeback >> > > Which Shorewall version?2.2.0-RC3 A.
Adam Sherman wrote:> Tom Eastep wrote: > >> If you have NEWNOTSYN=No then switch to NEWNOTSYN=Yes. If you have not >> >>>> already, set ''routeback'' on your local interface. >>> >>> >>> Both the above are already set. NEWNOTSYN=Yes in shorewall.conf and >>> routeback: >>> >>> loc br0 detect tcpflags,routeback >>> >> >> Which Shorewall version? > > > 2.2.0-RC3 >Please try setting DROPINVALID=No in shorewall.conf -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Tom Eastep wrote:>>>>Both the above are already set. NEWNOTSYN=Yes in shorewall.conf and >>>>routeback: >>>> >>>>loc br0 detect tcpflags,routeback >>> >>>Which Shorewall version? >> >>2.2.0-RC3 > > Please try setting DROPINVALID=No in shorewall.confThis fixes the problem. Although I had no such variable in shorewall.conf at all, needed to add it. Will this have any other ramifications? Thanks, A.
Adam Sherman wrote:>> >> Please try setting DROPINVALID=No in shorewall.conf > > > This fixes the problem. Although I had no such variable in > shorewall.conf at all, needed to add it.Which simply means that your shorewall.conf file is from an earlier release that didn''t support the variable.> > Will this have any other ramifications? >You may get a few more log messages. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key