The log just says that sometimes it chooses 0.0.0.0 as source, sometimes the gateway local Ip and sometimes the correct Public IP. Dont know if the problem is that left is %any as you proposed?
Also, Strongswan pick the LAN shunt connection for some incoming connections attempts. Another issue with the full tunnel connection, when it doesnt suceed connecting it still puts default route and all internet gets cut off. Ideally this should be done after connection is established? Also having issues stopping and restarting. Log file says that charon isnt responding and had to be killed. As you can se, it just starten acting weird... ---- 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
