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" <[email protected]>
> To: "Thor Simon" <[email protected]>, "Michael .." <[email protected]>,
> "[email protected]" <[email protected]>
> 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:[email protected]]
>> Sent: Wednesday, April 11, 2018 1:45 PM
>> To: Thor Simon <[email protected]>; Michael .. <[email protected]>;
>> [email protected]
>> 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:[email protected]] On Behalf Of Noel
>>> Kuntze
>>> Sent: Wednesday, April 11, 2018 1:23 PM
>>> To: Michael .. <[email protected]>; [email protected]
>>> 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.
