I''m having a problem where transferring files accross our IPsec gateway to another host on a remote network is failing. I see no packets being rejected in the logs. Attached is a packet trace, showing the problem. In this case, 10.100.0.0/24 is the local network and 10.100.14.0/24 is the remote network. The trace was taken on the local gateway. In the trace, there is a set of TCP retransmissions. Shortly after that, the client gets an error: "The specified network name is no longer available." Small files do copy successfully, 1KB. I don''t see anything in racoon''s logs either. Any ideas? Particularly where to look next? Thanks, A.
Adam Sherman wrote:> I''m having a problem where transferring files accross our IPsec gateway > to another host on a remote network is failing. I see no packets being > rejected in the logs. > > Attached is a packet trace, showing the problem. In this case, > 10.100.0.0/24 is the local network and 10.100.14.0/24 is the remote > network. The trace was taken on the local gateway. > > In the trace, there is a set of TCP retransmissions. Shortly after that, > the client gets an error: "The specified network name is no longer > available." > > Small files do copy successfully, 1KB. I don''t see anything in racoon''s > logs either. > > Any ideas? Particularly where to look next? >Check out the DROPINVALID change in 2.2.0/2.0.16 -- particularly the part about setting entries in /proc. -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:>>I''m having a problem where transferring files accross our IPsec gateway >>to another host on a remote network is failing. I see no packets being >>rejected in the logs. >> >>Attached is a packet trace, showing the problem. In this case, >>10.100.0.0/24 is the local network and 10.100.14.0/24 is the remote >>network. The trace was taken on the local gateway. >> >>In the trace, there is a set of TCP retransmissions. Shortly after that, >>the client gets an error: "The specified network name is no longer >>available." >> >>Small files do copy successfully, 1KB. I don''t see anything in racoon''s >>logs either. >> >>Any ideas? Particularly where to look next? > > Check out the DROPINVALID change in 2.2.0/2.0.16 -- particularly the > part about setting entries in /proc.If you mean this:> The new kernel code can be disabled by including this command in > your /etc/shorewall/init file: > > echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberalI set that and we still get the same behaviour. Thanks, A.
Adam Sherman wrote:> > > If you mean this: > >> The new kernel code can be disabled by including this command in >> your /etc/shorewall/init file: >> >> echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal > > > I set that and we still get the same behaviour. >Well, I have to use the new ''mss='' option in /etc/shorewall/ipsec to solve similar problems. See http://shorewall.net/myfiles.htm. -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:> Adam Sherman wrote: >>If you mean this: >> >>> The new kernel code can be disabled by including this command in >>> your /etc/shorewall/init file: >>> >>> echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal >> >>I set that and we still get the same behaviour. > > Well, I have to use the new ''mss='' option in /etc/shorewall/ipsec to > solve similar problems. See http://shorewall.net/myfiles.htm. >I had to grab the default ipsec file and add a single entry: net no - - mss=1400 Doesn''t seem to make a difference at all. The weird thing is that, out of our 20 tunnels, many of them do not have this issue. I''m at a loss. Thanks, A.
Adam Sherman wrote:> Tom Eastep wrote: > >> Adam Sherman wrote: >> >>> If you mean this: >>> >>>> The new kernel code can be disabled by including this command in >>>> your /etc/shorewall/init file: >>>> >>>> echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal >>> >>> >>> I set that and we still get the same behaviour. >> >> >> Well, I have to use the new ''mss='' option in /etc/shorewall/ipsec to >> solve similar problems. See http://shorewall.net/myfiles.htm. >> > > I had to grab the default ipsec file and add a single entry: > > net no - - mss=1400 > > Doesn''t seem to make a difference at all. The weird thing is that, out > of our 20 tunnels, many of them do not have this issue. > > I''m at a loss. >Can''t talk now -- two-hour staff meeting :-( -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
Adam Sherman wrote:>> > > I had to grab the default ipsec file and add a single entry: > > net no - - mss=1400 > > Doesn''t seem to make a difference at all.Are you SURE that''s the appropriate line for you -- I need to set mss=1400 on my gateway''s ''net'' interface so that connections coming *from* the IPSEC tunnel that go to the net are clamped.> The weird thing is that, out > of our 20 tunnels, many of them do not have this issue.So what is common about the *other* end of the problem tunnels? -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:> Adam Sherman wrote: >>I had to grab the default ipsec file and add a single entry: >> >>net no - - mss=1400 >> >>Doesn''t seem to make a difference at all. > > Are you SURE that''s the appropriate line for you -- I need to set > mss=1400 on my gateway''s ''net'' interface so that connections coming > *from* the IPSEC tunnel that go to the net are clamped.Ah, I see what you''re saying. What I want is for connections coming from the local network and going into an IPsec tunnel to be clamped. Not sure how to achieve that.>>The weird thing is that, out >>of our 20 tunnels, many of them do not have this issue. > > So what is common about the *other* end of the problem tunnels?I will do a comparison and get back to you. A.
Adam Sherman wrote:> > Ah, I see what you''re saying. What I want is for connections coming from > the local network and going into an IPsec tunnel to be clamped. Not sure > how to achieve that.Adam -- please look at the file and TRY. If you have specific questions, I''ll try to answer them.> >>> The weird thing is that, out >>> of our 20 tunnels, many of them do not have this issue. >> >> >> So what is common about the *other* end of the problem tunnels? > > > I will do a comparison and get back to you. >Don''t -- this is YOUR problem, not mine so please don''t try to make it mine. I make my living designing operating systems for HP and Linux networking is only my hobby. The only role that I have here is to help you get to the point where you can solve your on problems; you aren''t going to get there if I do all of the analysis of your problems. Referring to your other thread ("Architecture Help: OpenVPN"). You have 20 tunnels and I have one (or two if I can figure out a way to be two places at once) -- do you really want my advice??? -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