[strongSwan] Single physical interface "roadwarrior" responder using DHCP/FARP
Thor.Simon at twosigma.com
Wed Apr 11 23:47:25 CEST 2018
In our case, the clients receive addresses (by DHCP) that are within the subnet of one of the server's interfaces -- so if a packet arrives that's destined for a client who's been gone too lone, indeed it does attempt to resolve the address by ARP and obligingly generates an unreachable (which we then drop).
This will commonly be the case when both DHCP and FARP are in use, no? _Who_ can't layer-2 resolve the address and thus generates the problematic unreachable will depend on the ARP cache lifetime on the inbound gateway for the network. Configurations that are using DHCP with a routed block of client addresses of course won't see such problems (but they will have other problems of their own, such as the need to wait for a dynamic routing protocol to converge before client traffic can move, in multi-server designs).
From: Noel Kuntze <noel.kuntze+strongswan-users-ml at thermi.consulting>
Sent: Wednesday, April 11, 2018 2:50 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
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.
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.
> -----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
>> On 11.04.2018 18:56, Michael .. wrote:
>>> I'm trying to configure a responder for use in a "roadwarrior" scenario, albeit unsuccessfully.
>>> -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.
>>> conn %default
>>> conn rw
>>> -ip route show table 220
>>> 192.168.1.50 via 192.168.1.254 dev eth0 proto static
>>> 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?
More information about the Users