[strongSwan] Tunnels with dynamic IP and another route issue

[noel.kuntze+strongswan-users-ml at thermi.consulting]

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
>10.1.1.0/26 dev br0  proto static  src 10.1.1.1 # LAN passthrough?
>default via 85.24.x.x dev vlan847  proto static  src 10.1.1.1
>
>So instead of a route to 192.168.1.0/24 a default route is added, but
>it 
>looks like it doesn't go through the tunnel... traffic to
>192.168.1.0/24 
>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
>way?
>>
>> I have changed rightsubnet locally to 0.0.0.0/0 and leftsubnet 
>> remotely to 0.0.0.0/0, 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 0.0.0.0/0 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
>it 
>>>> 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
>hack.
>>>
>>>> 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
>a 
>>>> 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
>vanished 
>>> (and the CHILD_SAs migrated?).
>>> No mobike and no connectivity: Timeout, if DPD is used. Otherwise
>the 
>>> 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>