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