On 03.05.2017 13:51, Dusan Ilic wrote: > By the way, it seems the order of shunt connections do matter. They don't. XFRM doesn't care about what order any policies are inserted, only the TS and the priority.
> 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 > <tel:0.0.0.0> connection. Sounds like you have a race condition between charon and the software that gets your network connection(s) up. Make charon start after that software is done. I can't tell for certain though, because you don't share the logs. > > ---- 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 > > > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
