[strongSwan] Tunnels with dynamic IP and another route issue

noel.kuntze+strongswan-users-ml at thermi.consulting noel.kuntze+strongswan-users-ml at thermi.consulting
Sun Apr 30 20:39:01 CEST 2017

Fix your NAT rules.

Am 30. April 2017 12:28:48 MESZ schrieb Dusan Ilic <dusan at comhem.se>:
>Okey, so I found info about adding a "passthrough" connection for my 
>local LAN. I have done this now and when i start the connection the 
>network connection isn't cut off, however, it seems like my internet 
>traffic i still using my local gateway (browsed to a check my ip-page).
>I can however still ping the remote network.
>Here is my tabel 220
># ip route show table 220
> dev br0  proto static  src # LAN passthrough?
>default via 85.24.x.x dev vlan847  proto static  src
>So instead of a route to a default route is added, but
>looks like it doesn't go through the tunnel... traffic to
>do get tunneled still though.
>Den 2017-04-30 kl. 11:59, skrev Dusan Ilic:
>> Hello again,
>> It worked with the hack! Thank you!
>> Last question (hopefully! :P)), if I would like to use the remote 
>> endpoint to route *all* traffic over the vpn, is below the correct
>> I have changed rightsubnet locally to and leftsubnet 
>> remotely to, I have also added NAT on the remote router for
>> the local subnet on the local endpoint, and finally I have added the 
>> local subnet to table 220 on the local router. I have also replaced 
>> the Iptable forward rule on local endpoint with instead of 
>> only the remote subnet.
>> However, when I up the connection on the local router in a couple of 
>> seconds my SSH connection stops responding, and I cannot reach the 
>> local gateway or internet any longer. I have to reboot the local 
>> router to get access again.
>> Is this familiar to you? What could be happening here?
>> Den 2017-04-29 kl. 18:44, skrev Noel Kuntze:
>>> Hello Dusan,
>>> On 29.04.2017 18:34, Dusan Ilic wrote:
>>>> It works! I found a hidden setting under Phase 1 in Fortigate where
>>>> i could add the local ID. Added it's dynamic dns hostname and now
>>>> connects.
>>> Great!
>>>> However, I still have issues with another endpoint I'm testing. My 
>>>> local endpoint have Strongswan 5.5.1 and the remote endpoint have 
>>>> 4.5.2. Would that present any issues or incompatibilites? 
>>>> Unfortunately it's not possible to upgrade the remote endpoint 
>>>> (Strongswan).
>>> Pluto resolves IDs that are FQDNs. I think there was a hack, where 
>>> you add the at-character in front of the FQDN in the ID settings and
>>> that stops it from doing that.
>>> Might apply to charon, too in such a low version number. Try the
>>>> I tried below, per your suggestion
>>>> left=%local.example
>>>> leftid=local.example
>>>> right=%remote.example
>>>> rightid=remote.example
>>>> remote.example : PSK "PSKGOESHERE"
>>>> Log when local sides initiates connection:
>>>> parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]
>>>> received AUTHENTICATION_FAILED notify error
>>> You need to read the remote logs when the remote side sends you an 
>>> error message.
>>>> Log when remote side initiates connection:
>>>> Apr 29 16:32:20 R6250 daemon.info charon: 10[CFG] looking for peer 
>>>> configs matching 85.24.x.x[85.24.x.x]...94.254.x.x[94.254.x.x]
>>>> Apr 29 16:32:20 R6250 daemon.info charon: 10[CFG] no matching peer 
>>>> config found
>>>> It looks like the same issue, the remote endpoint doesnt send the 
>>>> configured ID?
>>> Yes.
>>>> And another question, when using dynamic hostnames instead of IP's 
>>>> as "right", how often does Strongswan make a new DNS-lookup? How 
>>>> does Strongswan handle the situation where let's say the remote 
>>>> endpoint suddenly receives a new IP? Or if the local side receives
>>>> new IP during established connection?
>>> strongSwan does a DNS lookup whenever it tries to select a 
>>> configuration. Well, depends on if mobike is used or no and if the 
>>> peer who's IP changed can't send any traffic anymore.
>>> Mobike and connectivity: IKE_SA and CHILD_SAs are migrated
>>> No mobike and connectivity: Don't know. Maybe a new IKE_SA is 
>>> negotiated, because the one peer knows the local address has
>>> (and the CHILD_SAs migrated?).
>>> No mobike and no connectivity: Timeout, if DPD is used. Otherwise
>>> IKE_SA and CHILD_SAs remain until the remote peer connects again.
>>> Mobike and no connectivity: Timeout, if DPD is used. Otherwise the 
>>> IKE_SA and CHILD_SAs remain until the remote peer connects again.
>>> Kind regards,
>>> Noel
>> _______________________________________________
>> Users mailing list
>> Users at lists.strongswan.org
>> https://lists.strongswan.org/mailman/listinfo/users

Sent from mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20170430/8af3aaf3/attachment.html>

More information about the Users mailing list