Hi Noel,
 
Little confused...
 
Adding (actually uncommenting) the following in sysctl.conf did not resolve the 
issue:
net.ipv4.conf.all.send_redirects = 0
 
Adding specifically just the following (in line with your original suggestion?) 
did resolve the issue, however the ICMP redirect is still observed:
net.ipv4.conf.eth0.send_redirects = 0
 
I had to have both lines present to resolve the issue and stop the ICMP 
redirect being sent.  This didn't seem to make sense to me?
 
Michael.
 

Sent: Wednesday, April 11, 2018 at 10:40 PM
From: "Noel Kuntze" <noel.kuntze+strongswan-users-ml@thermi.consulting>
To: "Michael .." <mi...@usa.com>
Cc: "Thor Simon" <thor.si...@twosigma.com>, "users@lists.strongswan.org" 
<users@lists.strongswan.org>
Subject: Re: [strongSwan] Single physical interface "roadwarrior" responder 
using DHCP/FARP
Hi Michael,

>From https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt:

send_redirects - BOOLEAN
Send redirects, if router.
send_redirects for the interface will be enabled if at least one of
conf/{all,interface}/send_redirects is set to TRUE,
it will be disabled otherwise
Default: TRUE

I didn't expect you to globally enable sending of redirects.

Kind regards

Noel

On 11.04.2018 23:34, Michael .. wrote:
> Noel,
>  
> Thanks for the pointer on "net.ipv4.conf.INTERFACE.send_redirects" - resolved 
> the issue.
>  
> I had actually set "net.ipv4.conf.all.send_redirects" previously and thought 
> this just masked the issue (stopped the ICMP but not fixed the connectivity). 
>  Turns out I read the trace wrongly and it didn't have any impact - the 
> originally observed ICMP was still there too.
>  
> Interestingly, although setting "net.ipv4.conf.INTERFACE.send_redirects" 
> solves the issue (i.e the packets are routed), the ICMP redirect is actually 
> still sent.  Setting "net.ipv4.conf.all.send_redirects" as well completely 
> removes the ICMP.  Not sure if this is intentional or a bug somewhere?
>  
> Anyway, thanks again.
>  
> Michael.
>  
>
> Sent: Wednesday, April 11, 2018 at 7:50 PM
> From: "Noel Kuntze" <noel.kuntze+strongswan-users-ml@thermi.consulting>
> To: "Thor Simon" <thor.si...@twosigma.com>, "Michael .." <mi...@usa.com>, 
> "users@lists.strongswan.org" <users@lists.strongswan.org>
> Subject: Re: [strongSwan] Single physical interface "roadwarrior" responder 
> using DHCP/FARP
> Then don't generate any ICMP messages in the first place. Just drop the 
> traffic to roadwarrior IPs without connectivity.
> The kernel only generates Destination Unreachables, if iptables tells it to, 
> or it can't acquire the host's layer two address, if it is connected over 
> layer two.
>
> Kind regards
>
> Noel
>
> On 11.04.2018 20:21, Thor Simon wrote:
>> No. Dropping needs-frag would cripple connectivity, for sure. Nobody should 
>> ever, ever drop needs-frag.
>>
>> Dropping other types of unreachables complicates diagnosis, but can't 
>> actually _cause_ connectivity issues, since no protocol I'm aware of 
>> actually takes any corrective action in response to an unreachable of any 
>> other type. Though inelegant, what this achieves is that TCP at either end 
>> not tear down connections we wish to persist when the peer briefly loses 
>> connectivity.
>>
>> Our users want their TCP connections to stay up even when they do things 
>> like commute home or ride the subway. DPD will (should, must, really) tear 
>> down the IPsec state, but the StrongSwan DHCP module, along with our DHCP 
>> server configurations, will ensure that when the peer reconnects, it'll get 
>> the same address. So these long-lived connections need not die. 
>> Unfortunately, to _ensure_ they don't die, we have to block ICMP 
>> unreachables generated on either peer while the IPsec tunnel is down (as 
>> well as, due to implementation details elsewhere in our network, from the 
>> next-hop router on the server side). But never, of course, needs-frag.
>>
>> The need to block TTL Exceeded is an oddity of our setup with many servers 
>> running in parallel and would not exist for most other deployments, I'd 
>> think. But, inelegant as it may be -- if you have mobile clients that can 
>> lose connectivity for tens of minutes at a time, and you don't want their 
>> TCP connections falling over, some ICMP will have to be blocked. Or so it 
>> seems to me.
>>
>> Thor
>>
>> -----Original Message-----
>> From: Noel Kuntze [mailto:noel.kuntze+strongswan-users-ml@thermi.consulting]
>> Sent: Wednesday, April 11, 2018 1:45 PM
>> To: Thor Simon <thor.si...@twosigma.com>; Michael .. <mi...@usa.com>; 
>> users@lists.strongswan.org
>> Subject: Re: [strongSwan] Single physical interface "roadwarrior" responder 
>> using DHCP/FARP
>>
>> "problematic"? By dropping those ICMP messages, you effectively cripple the 
>> connectivity of those clients if problems occur.
>>
>> On 11.04.2018 19:35, Thor Simon wrote:
>>> An alternative approach, which will also help if you have clients whose TCP 
>>> connections are dropped when they have transient connectivity failures, is 
>>> to use the packet filter to drop most (but not quite all) ICMP. In a 
>>> similar configuration to yours, we've ended up passing echo/echorep and 
>>> needs-frag; which means we drop redirects, ttl exceeded, and most 
>>> unreachables, all of which, in practice, with our large population of 
>>> mobile clients, ended up being problematic.
>>>
>>> -----Original Message-----
>>> From: Users [mailto:users-boun...@lists.strongswan.org] On Behalf Of Noel 
>>> Kuntze
>>> Sent: Wednesday, April 11, 2018 1:23 PM
>>> To: Michael .. <mi...@usa.com>; users@lists.strongswan.org
>>> Subject: Re: [strongSwan] Single physical interface "roadwarrior" responder 
>>> using DHCP/FARP
>>>
>>> Hello Michael,
>>>
>>> Disable sending of redirects for traffic on that interface.
>>> The key is "net.ipv4.conf.INTERFACE.send_redirects".
>>>
>>> Kind regards
>>>
>>> Noel
>>>
>>> On 11.04.2018 18:56, Michael .. wrote:
>>>> Hi,
>>>>  
>>>> I'm trying to configure a responder for use in a "roadwarrior" scenario, 
>>>> albeit unsuccessfully.
>>>>  
>>>> Topology/Config:
>>>>  
>>>> -ip route
>>>> default via 192.168.1.254 dev eth0 src 192.168.1.1 metric 202
>>>> 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.1 metric 202
>>>>  
>>>> Default gateway @ 192.168.1.254 provides internet access and also inbound 
>>>> NAT forwarding of ports 500/4500 from an internet IP.
>>>>  
>>>> -ipsec.conf:
>>>>  
>>>>
>>>> conn %default
>>>>     ikelifetime=60m
>>>>     keylife=20m
>>>>     rekeymargin=3m
>>>>     keyingtries=1
>>>>     keyexchange=ikev1
>>>> conn rw
>>>>     left=192.168.1.1
>>>>     leftsubnet=0.0.0.0/0
>>>>     leftauth=psk
>>>>     right=%any
>>>>     rightauth=psk
>>>>     rightauth2=xauth
>>>>     auto=add
>>>>     rightsourceip=%dhcp
>>>>  
>>>> -ip route show table 220
>>>> 192.168.1.50 via 192.168.1.254 dev eth0 proto static
>>>>  
>>>> Symptoms:
>>>>  
>>>> I am able to establish a VPN connection from the internet to the responder 
>>>> and the client is assigned an IP from the DHCP pool.
>>>>  
>>>> The responder can ping the client's IP address assigned from DHCP - 
>>>> therefore 2-way communication over the tunnel.  The remote internet client 
>>>> can also send packets over the tunnel to the rest of the 192.168.1.0/24 
>>>> subnet which reach their destination (e.g. to 192.168.1.2).  The responder 
>>>> then correctly replies to ARP on behalf of the clients address (e.g. 
>>>> 192.168.1.50) and the return packet arrives to the responders interface.  
>>>> However, the responder is replying with ICMP redirect to 192.168.1.254 to 
>>>> the sender and therefore the return packet does not reach the client.
>>>>  
>>>> Any ideas?
>>>>  
>>>> Cheers,
>>>>  
>>>> Michael.

Reply via email to