By the way, it seems the order of shunt connections do matter. If I put it at the end after all other connections the network gets completely cut off...looks like I have to put it directly after the 0.0.0.0 connection.
---- Noel Kuntze skrev ---- > > >On 02.05.2017 17:41, Dusan Ilic wrote: >> >> I see, thank you. >> >> Well, I seem to have random issues now with my new configuration. >> >> After restartin Strongswan sometiems it works, sometimes it don't Very >> unreliable. >> Sometimes it connects with right source interface, sometimes sending packet: >> from 0.0.0.0[500] to 94.x.x.x[500] (1316 bytes) and this won't work >> obviously. Why 0.0.0.0? >> When it connects from the right public WAN IP, sometimes it connects, >> sometimes just retransmittings a bunch of packets. Never had these problemse >> before, and I'm confused what's started causing them now. >> >Read your logs and compare them. >> >> >> *Regarding shunt connections, does it matter in which order they are put in >> ipsec.conf? Like at the top, or the bottom and so on?* >> > >No. >* >* >> >> >> Den 2017-05-02 kl. 09:41, skrev Noel Kuntze: >>> 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 >> > >
_______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
