[strongSwan] Single physical interface "roadwarrior" responder using DHCP/FARP

[Noel Kuntze]

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 at thermi.consulting>
> To: "Thor Simon" <Thor.Simon at twosigma.com>, "Michael .." <mikey at usa.com>, "users at lists.strongswan.org" <users at 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 at thermi.consulting]
>> Sent: Wednesday, April 11, 2018 1:45 PM
>> To: Thor Simon <Thor.Simon at twosigma.com>; Michael .. <mikey at usa.com>; users at 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-bounces at lists.strongswan.org] On Behalf Of Noel Kuntze
>>> Sent: Wednesday, April 11, 2018 1:23 PM
>>> To: Michael .. <mikey at usa.com>; users at 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.