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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
