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