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


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 dev eth0 src metric 202
>>>> dev eth0 proto kernel scope link src metric 202
>>>> Default gateway @ 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=
>>>>     leftsubnet=
>>>>     leftauth=psk
>>>>     right=%any
>>>>     rightauth=psk
>>>>     rightauth2=xauth
>>>>     auto=add
>>>>     rightsourceip=%dhcp
>>>> -ip route show table 220
>>>> via 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 
>>>> subnet which reach their destination (e.g. to  The responder 
>>>> then correctly replies to ARP on behalf of the clients address (e.g. 
>>>> and the return packet arrives to the responders interface.  
>>>> However, the responder is replying with ICMP redirect to to 
>>>> the sender and therefore the return packet does not reach the client.
>>>> Any ideas?
>>>> Cheers,
>>>> Michael.

Reply via email to