Yes, that's the reason why that happens. No, you need to start using another 
subnet.

On 02.05.2017 02:02, Dusan Ilic wrote:
> I seem to have found the problem, it was on my local endpoint. The gateway 
> have default IP-table rules in prerouting table dropping traffic entering any 
> WAN-interface destined to a LAN-subnet, which I understand is normal as long 
> as their isn't any IPsec involved :) Below exlude rule solves it.
>
> iptables -t mangle -I PREROUTING -d 10.1.1.0/26 -i $(nvram get wan3_ifname) 
> -m policy --dir in --pol ipsec --proto esp -j ACCEPT
>
>
> Now routing everything over IP-sec tunnel works great, but instead a new 
> issue have risen. My VPN remote access users cannot reach the internet 
> anymore (or the local subnet for that matter) when the gateway are routing 
> all traffic over another IPsec-tunnel, and from the LAN I cannot ping the 
> VPN-client (Android Strongswan) either. I'm wildly guessing this is because 
> my VPN-clients are getting IP's from the local subnet (rightsourceip=%dhcp), 
> the same subnet that I have to create a passthrough connection for. Is this 
> solvable in an easy way, or am I forced put my VPN-clients on a separate 
> subnet?
>
> Den 2017-05-01 kl. 14:57, skrev Noel Kuntze:
>> I can't  help you further easily. You need to check what happens to the 
>> packets and what actually needs to happen.
>>
>> On 30.04.2017 23:25, Dusan Ilic wrote:
>>> I have added following on local router
>>>
>>> iptables -t nat -I POSTROUTING -s 10.1.1.0/26 -o vlan847 -m policy --dir 
>>> out --pol ipsec --proto esp -j ACCEPT
>>> (before it was iptables -t nat -I POSTROUTING -s 10.1.1.0/26 -d 
>>> 192.168.1.0/24 -o vlan847 -m policy --dir out --pol ipsec --proto esp -j 
>>> ACCEPT)
>>>
>>> And on remote router
>>>
>>> iptables -I FORWARD -s 10.1.1.0/26 -j ACCEPT
>>> iptables -t nat -I POSTROUTING -s 10.1.1.0/26 -j MASQUERADE
>>>
>>> And now when the tunnel is up, internet doesnt work at all (all pings time 
>>> out), however I can still reach the remote subnet 192.168.1.0. What is the 
>>> best way to troubleshoot, if the error is on the local gateway or on the 
>>> remote?
>>>
>>>
>>> Den 2017-04-30 kl. 20:39, skrev 
>>> [email protected]:
>>>> Fix your NAT rules.
>>>>
>>>> Am 30. April 2017 12:28:48 MESZ schrieb Dusan Ilic <[email protected]>:
>>>>
>>>>      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 <http://10.1.1.0/26> dev br0  proto static  src 10.1.1.1 
>>>> <http://10.1.1.1> # LAN passthrough?
>>>>      default via 85.24.x.x dev vlan847  proto static  src 10.1.1.1 
>>>> <http://10.1.1.1>
>>>>
>>>>      So instead of a route to 192.168.1.0/24 <http://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 <http://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 <http://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 <http://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 [email protected] 
>>>> https://lists.strongswan.org/mailman/listinfo/users
>>>>
>>>>
>>>> Sent from mobile
>>
>
>


Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Users mailing list
[email protected]
https://lists.strongswan.org/mailman/listinfo/users

Reply via email to