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