Okey, I will try some things out and see if it gets better. If not I
will return with some logs :)
I'm just thinking out loud here regarding Charon source route selection,
because you proposed leaving out the "left"-parameter (defaulting to
%any I think) and my router is multihomed, what about if I mangle the
output packets on UDP port 500 through the right WAN interface routing
table? Will that force charon traffic out the right interface too?
Or maybe if I exlude all routing tables present on the gateway (except
the one I want) in strongswan.conf, then that shoud force Charon to do
source route lookups in this table only?
I have made some completely different observations, I tried running
Strongswan with libipsec instead of kernel modules and noticed two things.
1. The shunt policy doesn't work anymore, the route for local LAN gets
created with dev ipsec0 (instead of br0). Is this a known bug? I had to
add a manual route to table 220.
2. It's easier to route, maintain and so on because all traffic goes
in/out on a dedicated interface (ipsec0), so no need for IP-tables
policy matching. However, it's noticeable slower (througput) and when
transferring traffic my routers almost hits 100% cpu load. Is this normal?
With kernel modules I can reach double the througput (20 vs 50Mbps),
however then the CPU is only around 50%. What do you think is the bottle
neck here for achieving higher throughput? The remote endpoint? With
Android Strongswan client it's even slower than that (tested on WiFi).
Both sides of the WAN-connection in this case have 100Mbps, so that's
ruled out.
Den 2017-05-03 kl. 16:23, skrev Noel Kuntze:
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
_______________________________________________
Users mailing list
[email protected]
https://lists.strongswan.org/mailman/listinfo/users
