Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Dusan Ilic]

Sorry, other way around, 32666 and 220 works, but 0 doesn't.

0:  from all lookup local
101:from 90.225.194.x lookup WAN1
102:from 10.248.0.x lookup WAN2
103:from 85.24.240.x lookup WAN3
121:from all fwmark 0x100/0xf00 lookup WAN1
122:from all fwmark 0x200/0xf00 lookup WAN2
123:from all fwmark 0x300/0xf00 lookup WAN3
220:from all lookup main
32766:  from all lookup main
32767:  from all lookup default

Den 2017-05-06 kl. 17:51, skrev Noel Kuntze:


On 03.05.2017 13:27, Dusan Ilic wrote:

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?

No. It's a race condition in your network initialization. You need to make sure 
your routes have source hints.


Also, Strongswan pick the LAN shunt connection for some incoming connections 
attempts.


That's because you don't bind them to localhost with left=127.0.0.1 and 
right=127.0.0.1. Charon doesn't exclude shunt configurations when doing a 
configuration lookup for other peers.


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?

Logs.


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...

Logs.



___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Dusan Ilic]

Source hints?
I dont think so, I have noticed that it depends on which routing table 
in strongswn.conf is configured for charon to install routes. The 
behaviour seem different if I use 220, table 0 or main routing table. I 
think if I use main routing table for route installation the source IP 
of the IKE transmission is 0.0.0.0, if I choose 0 or 220 its correct. 
Strange, having a hard time really grasping how all of this works "under 
the hood"...


Your right, it works much better now when added left/right=127.0.0.1. 
Thanks!


The two other issues seem to have gone away after modifications to 
routing tables, strongswan.conf and so on. Tried everything, almost 
impossible to remember what solves what :)



Den 2017-05-06 kl. 17:51, skrev Noel Kuntze:


On 03.05.2017 13:27, Dusan Ilic wrote:

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?

No. It's a race condition in your network initialization. You need to make sure 
your routes have source hints.


Also, Strongswan pick the LAN shunt connection for some incoming connections 
attempts.


That's because you don't bind them to localhost with left=127.0.0.1 and 
right=127.0.0.1. Charon doesn't exclude shunt configurations when doing a 
configuration lookup for other peers.


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?

Logs.


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...

Logs.



___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Dusan Ilic]

There is nothing in the logs, i'm downing the tunnel then starting a 
ping from a client to get it up while tailing the log file on the 
gateway. Nothing related to that tunnel are shown at all...


The only tunnel that goes up by traffic is the tunnel with rightsubnet 
0.0.0.0. When I disable that tunnel, the other tunnels start to work. 
With the 0.0.0.0 tunnel up, I have to manually up the tunnel or wait for 
the peer to initiate the connection.


Below you have my complete config

config setup
uniqueids = never

conn %default
auto=route
keyexchange=ikev2
type=tunnel
dpdaction=restart
leftauth=psk
rightauth=psk
left=%any
leftsubnet=10.1.1.0/26

# - - - - - - - - - - - -
# Passthrough connections
# - - - - - - - - - - - -

conn lan
authby=never
type=passthrough
left=127.0.0.1
leftsubnet=10.1.1.0/26
right=127.0.0.1
rightsubnet=10.1.1.0/26,10.1.2.0/26,255.255.255.255/32

conn lan2
also=lan
leftsubnet=10.1.2.0/26
rightsubnet=10.1.2.0/26

conn iptv
also=lan
leftsubnet=10.1.1.0/26
rightsubnet=90.225.194.0/24,194.236.188.130/32,194.22.194.0/24

conn integrity
also=lan
leftsubnet=10.1.1.1/32
rightsubnet=94.254.51.231/32

# - - - - - - - - - - - -
# Site to Site
# - - - - - - - - - - - -

conn wesafe
keylife=10800s
ikelifetime=28800s
ike=aes128-sha1-modp2048
esp=aes128-sha1
right=%example.com
rightid=example.com
rightsubnet=192.168.1.0/24

conn test
keylife=3600s
ikelifetime=28800s
ike=aes128-sha1-modp1024!
esp=aes128-sha1-modp1024!
right=%example.com
rightid=example.com
rightsubnet=0.0.0.0/0

conn azure
keylife=27000s
ikelifetime=28800s
ike=aes128-sha1-modp1024
esp=aes128-sha1
right=x.x.x.x
rightsubnet=10.0.1.0/24

# - - - - - - - - - - - -
# Remote Access
# - - - - - - - - - - - -


conn vpn
auto=add
dpdaction=clear
dpddelay=300s
mobike=yes

leftid=example.com
leftsubnet=0.0.0.0/0
leftauth=pubkey

right=%any
rightsubnet=%dynamic
rightsourceip=%dhcp
rightauth=eap-mschapv2

eap_identity=%any

Den 2017-05-06 kl. 17:49, skrev Noel Kuntze:

On 06.05.2017 14:29, Dusan Ilic wrote:

Sorry to say I didnt follow you completely, what do you mean? Dont disabling 
route installation effectively mean that im forced to setup the same with 
updown-scriprs?
Also, whats the difference setting a fwmark with netlink plugin? What behaviour 
changes?

No, in you case, you don't need any extra routes. Just disable it. With the 
fwmark set, charon can exclude routing table 220 when doing route lookups.


One observation, it looks like ignoring routing tables doesnt work. Ive tried 
ignoring every single one and still charon is able to initiatie, how is this 
possible?

Dunno.


Also, when having a 0.0.0.0 tunnel all other tunnels wont go up on traffic if 
start=route is set. Any idea why?


Dunno. Provide your configuration and logs.



___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Noel Kuntze]

On 03.05.2017 13:27, Dusan Ilic wrote:
> 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?

No. It's a race condition in your network initialization. You need to make sure 
your routes have source hints.

> 
> Also, Strongswan pick the LAN shunt connection for some incoming connections 
> attempts.
> 

That's because you don't bind them to localhost with left=127.0.0.1 and 
right=127.0.0.1. Charon doesn't exclude shunt configurations when doing a 
configuration lookup for other peers.

> 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?

Logs.

> 
> 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...

Logs.



signature.asc
Description: OpenPGP digital signature
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Noel Kuntze]

On 06.05.2017 14:29, Dusan Ilic wrote:
> Sorry to say I didnt follow you completely, what do you mean? Dont disabling 
> route installation effectively mean that im forced to setup the same with 
> updown-scriprs?
> Also, whats the difference setting a fwmark with netlink plugin? What 
> behaviour changes?

No, in you case, you don't need any extra routes. Just disable it. With the 
fwmark set, charon can exclude routing table 220 when doing route lookups.

> One observation, it looks like ignoring routing tables doesnt work. Ive tried 
> ignoring every single one and still charon is able to initiatie, how is this 
> possible?

Dunno.

> 
> Also, when having a 0.0.0.0 tunnel all other tunnels wont go up on traffic if 
> start=route is set. Any idea why?
> 
Dunno. Provide your configuration and logs.



signature.asc
Description: OpenPGP digital signature
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Dusan Ilic]

Sorry to say I didnt follow you completely, what do you mean? Dont disabling 
route installation effectively mean that im forced to setup the same with 
updown-scriprs?
Also, whats the difference setting a fwmark with netlink plugin? What behaviour 
changes?

One observation, it looks like ignoring routing tables doesnt work. Ive tried 
ignoring every single one and still charon is able to initiatie, how is this 
possible?

Also, when having a 0.0.0.0 tunnel all other tunnels wont go up on traffic if 
start=route is set. Any idea why?

 Noel Kuntze skrev 

>As far as I can tell, there is effectively no useful change with charon 
>installing any routes in your case, because in your setup,
>there aren't going to be any more network reachable over a non-default route.
>
>On 05.05.2017 23:43, Dusan Ilic wrote:
>> Hello Noel,
>> 
>> You keep suggesting disabling route installation (and before also a random 
>> fwmark in netlink plugin), well, could you explain a little more detailed 
>> what would/should happen if I follow these instructions, and also what else 
>> I will have to do? I mean, without routes there will be no routing obviously 
>> :)
>> 
>> Never the less, thank you for your feedback on the routing table.
>> 
>> 
>> Den 2017-05-05 kl. 21:38, skrev Noel Kuntze:
>>> Hello Dusan,
>>>
>>> On 05.05.2017 08:55, Dusan Ilic wrote:
 Okey, so I have tried different things now and I think that Charon source 
 routing seem to work better (atleast it looks like if after a couple of 
 reboots of the gateway). Im not source what did it, because I have both 
 added an Iptable mangling rule for UDP port 500 (IKE) marrking out the WAN 
 interface I want to use for IPsec, and changed settings so that Charon 
 ignores all but one routing table and also only listens to this interface 
 (and LAN), not the other WAN-interfaces. I have tried to force it in every 
 possible way to only do it's route lookup/next hop in ONE table for the 
 right WAN-interface.
>>> You could try to disable the installation of routes in strongswan.conf 
>>> (charon.install_routes = no).
>>>
 However, the more I try the more I seem to understand that Strongswan 
 seems not to be good at handling a bit more advanced routing setups. My 
 new issue is that my other LAN (have two local subnets/VLANs) is also 
 routed out the 0.0.0.0 ipsec connection now, even though it isn't part of 
 the TS-selectors. My main LAN is on br0 and my second LAN on br1. I have 
 even tried creating a separate passthrough for the second LAN, but Charon 
 oddly creates the passthrough route out on the WAN IP-sec interface 
 (instead of br1).
>>> Weird. To be honest, if you make charon not install any routes, just the 
>>> policies are added and traffic isn't routed differently.
>>>
 It looks like the biggest problem now is the 0.0.0.0 tunnel, by default a 
 default route is added to table 220. If I change charon routing table to 
 main table, Charon adds two new routes (I think cover the whole Internet) 
 and leaves the default main route (multipath netxhop route). However, 
 because the second LAN isn't a part of the 0.0.0.0 connection TS-selector, 
 it won't be allowed out this default route and tunnel (and that's how I 
 want it). I would like the second LAN to use the ordinary default routes 
 to reach the internet, and I'm really lost here how to handle Strongswan 
 with multiple default routes and/or routing tables with policy routing.
>>> See above.
>>>
 I know you said that Strongswan isn't adapted to work with multipath 
 routes and that sort of routing (loadbalancing), however, it seems that it 
 has issues with systems with several routing tables too. Do you have any 
 recommendations how I should go on from here, or is it just that simple 
 that Strongswan isn't going to be working reliably in an advanced routing 
 setup?
>>> See above.
>>>
 I'm pasting all of my gateways routing and policy routing setup below, if 
 that is of any help.

 # ip route show
 90.225.194.1 dev vlan845  scope link
 85.24.240.1 dev vlan847  scope link
 85.24.244.1 dev vlan846  scope link
 10.248.0.x dev ppp1  scope link
 10.1.1.0/26 dev br0  proto kernel  scope link  src 10.1.1.1
 10.1.2.0/26 dev br1  proto kernel  scope link  src 10.1.2.1
 90.225.194.0/24 dev vlan845  proto kernel  scope link  src 90.225.194.x
 85.24.244.0/24 dev vlan846  proto kernel  scope link  src 85.24.244.x
 85.24.240.0/24 dev vlan847  proto kernel  scope link  src 85.24.240.x
 127.0.0.0/8 dev lo  scope link
 default
  nexthop via 90.225.194.1  dev vlan845 weight 1
  nexthop via 10.248.0.21  dev ppp1 weight 256
  nexthop via 85.24.240.1  dev vlan847 weight 1
 default via 85.24.244.1 dev vlan846  metric 1
>>> Besides from the superfluous loopback route, it looks fine. You 

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Noel Kuntze]

As far as I can tell, there is effectively no useful change with charon 
installing any routes in your case, because in your setup,
there aren't going to be any more network reachable over a non-default route.

On 05.05.2017 23:43, Dusan Ilic wrote:
> Hello Noel,
> 
> You keep suggesting disabling route installation (and before also a random 
> fwmark in netlink plugin), well, could you explain a little more detailed 
> what would/should happen if I follow these instructions, and also what else I 
> will have to do? I mean, without routes there will be no routing obviously :)
> 
> Never the less, thank you for your feedback on the routing table.
> 
> 
> Den 2017-05-05 kl. 21:38, skrev Noel Kuntze:
>> Hello Dusan,
>>
>> On 05.05.2017 08:55, Dusan Ilic wrote:
>>> Okey, so I have tried different things now and I think that Charon source 
>>> routing seem to work better (atleast it looks like if after a couple of 
>>> reboots of the gateway). Im not source what did it, because I have both 
>>> added an Iptable mangling rule for UDP port 500 (IKE) marrking out the WAN 
>>> interface I want to use for IPsec, and changed settings so that Charon 
>>> ignores all but one routing table and also only listens to this interface 
>>> (and LAN), not the other WAN-interfaces. I have tried to force it in every 
>>> possible way to only do it's route lookup/next hop in ONE table for the 
>>> right WAN-interface.
>> You could try to disable the installation of routes in strongswan.conf 
>> (charon.install_routes = no).
>>
>>> However, the more I try the more I seem to understand that Strongswan seems 
>>> not to be good at handling a bit more advanced routing setups. My new issue 
>>> is that my other LAN (have two local subnets/VLANs) is also routed out the 
>>> 0.0.0.0 ipsec connection now, even though it isn't part of the 
>>> TS-selectors. My main LAN is on br0 and my second LAN on br1. I have even 
>>> tried creating a separate passthrough for the second LAN, but Charon oddly 
>>> creates the passthrough route out on the WAN IP-sec interface (instead of 
>>> br1).
>> Weird. To be honest, if you make charon not install any routes, just the 
>> policies are added and traffic isn't routed differently.
>>
>>> It looks like the biggest problem now is the 0.0.0.0 tunnel, by default a 
>>> default route is added to table 220. If I change charon routing table to 
>>> main table, Charon adds two new routes (I think cover the whole Internet) 
>>> and leaves the default main route (multipath netxhop route). However, 
>>> because the second LAN isn't a part of the 0.0.0.0 connection TS-selector, 
>>> it won't be allowed out this default route and tunnel (and that's how I 
>>> want it). I would like the second LAN to use the ordinary default routes to 
>>> reach the internet, and I'm really lost here how to handle Strongswan with 
>>> multiple default routes and/or routing tables with policy routing.
>> See above.
>>
>>> I know you said that Strongswan isn't adapted to work with multipath routes 
>>> and that sort of routing (loadbalancing), however, it seems that it has 
>>> issues with systems with several routing tables too. Do you have any 
>>> recommendations how I should go on from here, or is it just that simple 
>>> that Strongswan isn't going to be working reliably in an advanced routing 
>>> setup?
>> See above.
>>
>>> I'm pasting all of my gateways routing and policy routing setup below, if 
>>> that is of any help.
>>>
>>> # ip route show
>>> 90.225.194.1 dev vlan845  scope link
>>> 85.24.240.1 dev vlan847  scope link
>>> 85.24.244.1 dev vlan846  scope link
>>> 10.248.0.x dev ppp1  scope link
>>> 10.1.1.0/26 dev br0  proto kernel  scope link  src 10.1.1.1
>>> 10.1.2.0/26 dev br1  proto kernel  scope link  src 10.1.2.1
>>> 90.225.194.0/24 dev vlan845  proto kernel  scope link  src 90.225.194.x
>>> 85.24.244.0/24 dev vlan846  proto kernel  scope link  src 85.24.244.x
>>> 85.24.240.0/24 dev vlan847  proto kernel  scope link  src 85.24.240.x
>>> 127.0.0.0/8 dev lo  scope link
>>> default
>>>  nexthop via 90.225.194.1  dev vlan845 weight 1
>>>  nexthop via 10.248.0.21  dev ppp1 weight 256
>>>  nexthop via 85.24.240.1  dev vlan847 weight 1
>>> default via 85.24.244.1 dev vlan846  metric 1
>> Besides from the superfluous loopback route, it looks fine. You should 
>> probably set a src hint on the route to ppp1.
>>
>>> # ip rule
>>> 0:  from all lookup local
>>> 101:from 90.225.194.x lookup WAN1
>>> 102:from 10.248.0.x lookup WAN2
>>> 103:from 85.24.240.x lookup WAN3
>>> 121:from all fwmark 0x100/0xf00 lookup WAN1
>>> 122:from all fwmark 0x200/0xf00 lookup WAN2
>>> 123:from all fwmark 0x300/0xf00 lookup WAN3
>>> 124:from all fwmark 0x400/0xf00 lookup WAN4
>>> 32766:  from all lookup main
>>> 32767:  from all lookup default
>>>
>>> Strongswan isn't running at the moment, that's way route table 220 is 
>>> missing above.
>>>
>>>
>>> Den 2017-05-04 kl. 14:52, skrev Dusan 

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Dusan Ilic]

Hello Noel,

You keep suggesting disabling route installation (and before also a 
random fwmark in netlink plugin), well, could you explain a little more 
detailed what would/should happen if I follow these instructions, and 
also what else I will have to do? I mean, without routes there will be 
no routing obviously :)


Never the less, thank you for your feedback on the routing table.


Den 2017-05-05 kl. 21:38, skrev Noel Kuntze:

Hello Dusan,

On 05.05.2017 08:55, Dusan Ilic wrote:

Okey, so I have tried different things now and I think that Charon source 
routing seem to work better (atleast it looks like if after a couple of reboots 
of the gateway). Im not source what did it, because I have both added an 
Iptable mangling rule for UDP port 500 (IKE) marrking out the WAN interface I 
want to use for IPsec, and changed settings so that Charon ignores all but one 
routing table and also only listens to this interface (and LAN), not the other 
WAN-interfaces. I have tried to force it in every possible way to only do it's 
route lookup/next hop in ONE table for the right WAN-interface.

You could try to disable the installation of routes in strongswan.conf 
(charon.install_routes = no).


However, the more I try the more I seem to understand that Strongswan seems not 
to be good at handling a bit more advanced routing setups. My new issue is that 
my other LAN (have two local subnets/VLANs) is also routed out the 0.0.0.0 
ipsec connection now, even though it isn't part of the TS-selectors. My main 
LAN is on br0 and my second LAN on br1. I have even tried creating a separate 
passthrough for the second LAN, but Charon oddly creates the passthrough route 
out on the WAN IP-sec interface (instead of br1).

Weird. To be honest, if you make charon not install any routes, just the 
policies are added and traffic isn't routed differently.


It looks like the biggest problem now is the 0.0.0.0 tunnel, by default a 
default route is added to table 220. If I change charon routing table to main 
table, Charon adds two new routes (I think cover the whole Internet) and leaves 
the default main route (multipath netxhop route). However, because the second 
LAN isn't a part of the 0.0.0.0 connection TS-selector, it won't be allowed out 
this default route and tunnel (and that's how I want it). I would like the 
second LAN to use the ordinary default routes to reach the internet, and I'm 
really lost here how to handle Strongswan with multiple default routes and/or 
routing tables with policy routing.

See above.


I know you said that Strongswan isn't adapted to work with multipath routes and 
that sort of routing (loadbalancing), however, it seems that it has issues with 
systems with several routing tables too. Do you have any recommendations how I 
should go on from here, or is it just that simple that Strongswan isn't going 
to be working reliably in an advanced routing setup?

See above.


I'm pasting all of my gateways routing and policy routing setup below, if that 
is of any help.

# ip route show
90.225.194.1 dev vlan845  scope link
85.24.240.1 dev vlan847  scope link
85.24.244.1 dev vlan846  scope link
10.248.0.x dev ppp1  scope link
10.1.1.0/26 dev br0  proto kernel  scope link  src 10.1.1.1
10.1.2.0/26 dev br1  proto kernel  scope link  src 10.1.2.1
90.225.194.0/24 dev vlan845  proto kernel  scope link  src 90.225.194.x
85.24.244.0/24 dev vlan846  proto kernel  scope link  src 85.24.244.x
85.24.240.0/24 dev vlan847  proto kernel  scope link  src 85.24.240.x
127.0.0.0/8 dev lo  scope link
default
 nexthop via 90.225.194.1  dev vlan845 weight 1
 nexthop via 10.248.0.21  dev ppp1 weight 256
 nexthop via 85.24.240.1  dev vlan847 weight 1
default via 85.24.244.1 dev vlan846  metric 1

Besides from the superfluous loopback route, it looks fine. You should probably 
set a src hint on the route to ppp1.


# ip rule
0:  from all lookup local
101:from 90.225.194.x lookup WAN1
102:from 10.248.0.x lookup WAN2
103:from 85.24.240.x lookup WAN3
121:from all fwmark 0x100/0xf00 lookup WAN1
122:from all fwmark 0x200/0xf00 lookup WAN2
123:from all fwmark 0x300/0xf00 lookup WAN3
124:from all fwmark 0x400/0xf00 lookup WAN4
32766:  from all lookup main
32767:  from all lookup default

Strongswan isn't running at the moment, that's way route table 220 is missing 
above.


Den 2017-05-04 kl. 14:52, skrev Dusan Ilic:

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 

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Noel Kuntze]

Hello Dusan,

On 05.05.2017 08:55, Dusan Ilic wrote:
> Okey, so I have tried different things now and I think that Charon source 
> routing seem to work better (atleast it looks like if after a couple of 
> reboots of the gateway). Im not source what did it, because I have both added 
> an Iptable mangling rule for UDP port 500 (IKE) marrking out the WAN 
> interface I want to use for IPsec, and changed settings so that Charon 
> ignores all but one routing table and also only listens to this interface 
> (and LAN), not the other WAN-interfaces. I have tried to force it in every 
> possible way to only do it's route lookup/next hop in ONE table for the right 
> WAN-interface.

You could try to disable the installation of routes in strongswan.conf 
(charon.install_routes = no).

> 
> However, the more I try the more I seem to understand that Strongswan seems 
> not to be good at handling a bit more advanced routing setups. My new issue 
> is that my other LAN (have two local subnets/VLANs) is also routed out the 
> 0.0.0.0 ipsec connection now, even though it isn't part of the TS-selectors. 
> My main LAN is on br0 and my second LAN on br1. I have even tried creating a 
> separate passthrough for the second LAN, but Charon oddly creates the 
> passthrough route out on the WAN IP-sec interface (instead of br1).

Weird. To be honest, if you make charon not install any routes, just the 
policies are added and traffic isn't routed differently.

> It looks like the biggest problem now is the 0.0.0.0 tunnel, by default a 
> default route is added to table 220. If I change charon routing table to main 
> table, Charon adds two new routes (I think cover the whole Internet) and 
> leaves the default main route (multipath netxhop route). However, because the 
> second LAN isn't a part of the 0.0.0.0 connection TS-selector, it won't be 
> allowed out this default route and tunnel (and that's how I want it). I would 
> like the second LAN to use the ordinary default routes to reach the internet, 
> and I'm really lost here how to handle Strongswan with multiple default 
> routes and/or routing tables with policy routing.

See above.

> 
> I know you said that Strongswan isn't adapted to work with multipath routes 
> and that sort of routing (loadbalancing), however, it seems that it has 
> issues with systems with several routing tables too. Do you have any 
> recommendations how I should go on from here, or is it just that simple that 
> Strongswan isn't going to be working reliably in an advanced routing setup?

See above.

> 
> I'm pasting all of my gateways routing and policy routing setup below, if 
> that is of any help.
> 
> # ip route show
> 90.225.194.1 dev vlan845  scope link
> 85.24.240.1 dev vlan847  scope link
> 85.24.244.1 dev vlan846  scope link
> 10.248.0.x dev ppp1  scope link
> 10.1.1.0/26 dev br0  proto kernel  scope link  src 10.1.1.1
> 10.1.2.0/26 dev br1  proto kernel  scope link  src 10.1.2.1
> 90.225.194.0/24 dev vlan845  proto kernel  scope link  src 90.225.194.x
> 85.24.244.0/24 dev vlan846  proto kernel  scope link  src 85.24.244.x
> 85.24.240.0/24 dev vlan847  proto kernel  scope link  src 85.24.240.x
> 127.0.0.0/8 dev lo  scope link
> default
> nexthop via 90.225.194.1  dev vlan845 weight 1
> nexthop via 10.248.0.21  dev ppp1 weight 256
> nexthop via 85.24.240.1  dev vlan847 weight 1
> default via 85.24.244.1 dev vlan846  metric 1

Besides from the superfluous loopback route, it looks fine. You should probably 
set a src hint on the route to ppp1.

> # ip rule
> 0:  from all lookup local
> 101:from 90.225.194.x lookup WAN1
> 102:from 10.248.0.x lookup WAN2
> 103:from 85.24.240.x lookup WAN3
> 121:from all fwmark 0x100/0xf00 lookup WAN1
> 122:from all fwmark 0x200/0xf00 lookup WAN2
> 123:from all fwmark 0x300/0xf00 lookup WAN3
> 124:from all fwmark 0x400/0xf00 lookup WAN4
> 32766:  from all lookup main
> 32767:  from all lookup default
> 
> Strongswan isn't running at the moment, that's way route table 220 is missing 
> above.
> 
> 
> Den 2017-05-04 kl. 14:52, skrev Dusan Ilic:
>> 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 

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Dusan Ilic]

Okey, so I have tried different things now and I think that Charon 
source routing seem to work better (atleast it looks like if after a 
couple of reboots of the gateway). Im not source what did it, because I 
have both added an Iptable mangling rule for UDP port 500 (IKE) marrking 
out the WAN interface I want to use for IPsec, and changed settings so 
that Charon ignores all but one routing table and also only listens to 
this interface (and LAN), not the other WAN-interfaces. I have tried to 
force it in every possible way to only do it's route lookup/next hop in 
ONE table for the right WAN-interface.


However, the more I try the more I seem to understand that Strongswan 
seems not to be good at handling a bit more advanced routing setups. My 
new issue is that my other LAN (have two local subnets/VLANs) is also 
routed out the 0.0.0.0 ipsec connection now, even though it isn't part 
of the TS-selectors. My main LAN is on br0 and my second LAN on br1. I 
have even tried creating a separate passthrough for the second LAN, but 
Charon oddly creates the passthrough route out on the WAN IP-sec 
interface (instead of br1).


It looks like the biggest problem now is the 0.0.0.0 tunnel, by default 
a default route is added to table 220. If I change charon routing table 
to main table, Charon adds two new routes (I think cover the whole 
Internet) and leaves the default main route (multipath netxhop route). 
However, because the second LAN isn't a part of the 0.0.0.0 connection 
TS-selector, it won't be allowed out this default route and tunnel (and 
that's how I want it). I would like the second LAN to use the ordinary 
default routes to reach the internet, and I'm really lost here how to 
handle Strongswan with multiple default routes and/or routing tables 
with policy routing.


I know you said that Strongswan isn't adapted to work with multipath 
routes and that sort of routing (loadbalancing), however, it seems that 
it has issues with systems with several routing tables too. Do you have 
any recommendations how I should go on from here, or is it just that 
simple that Strongswan isn't going to be working reliably in an advanced 
routing setup?


I'm pasting all of my gateways routing and policy routing setup below, 
if that is of any help.


# ip route show
90.225.194.1 dev vlan845  scope link
85.24.240.1 dev vlan847  scope link
85.24.244.1 dev vlan846  scope link
10.248.0.x dev ppp1  scope link
10.1.1.0/26 dev br0  proto kernel  scope link  src 10.1.1.1
10.1.2.0/26 dev br1  proto kernel  scope link  src 10.1.2.1
90.225.194.0/24 dev vlan845  proto kernel  scope link  src 90.225.194.x
85.24.244.0/24 dev vlan846  proto kernel  scope link  src 85.24.244.x
85.24.240.0/24 dev vlan847  proto kernel  scope link  src 85.24.240.x
127.0.0.0/8 dev lo  scope link
default
nexthop via 90.225.194.1  dev vlan845 weight 1
nexthop via 10.248.0.21  dev ppp1 weight 256
nexthop via 85.24.240.1  dev vlan847 weight 1
default via 85.24.244.1 dev vlan846  metric 1

# ip rule
0:  from all lookup local
101:from 90.225.194.x lookup WAN1
102:from 10.248.0.x lookup WAN2
103:from 85.24.240.x lookup WAN3
121:from all fwmark 0x100/0xf00 lookup WAN1
122:from all fwmark 0x200/0xf00 lookup WAN2
123:from all fwmark 0x300/0xf00 lookup WAN3
124:from all fwmark 0x400/0xf00 lookup WAN4
32766:  from all lookup main
32767:  from all lookup default

Strongswan isn't running at the moment, that's way route table 220 is 
missing above.



Den 2017-05-04 kl. 14:52, skrev Dusan Ilic:
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 

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Dusan Ilic]

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  
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), 

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[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 
>  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 
> > noel.kuntze+strongswan-users-ml@thermi.consulting:
> >> Fix your NAT rules.
> >>
> >> Am 30. April 2017 12:28:48 MESZ schrieb Dusan Ilic :
> >>
> >>  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  dev br0  proto static  src 
> >> 10.1.1.1  # LAN passthrough?
> >>  default via 85.24.x.x dev vlan847  proto static  src 10.1.1.1 
> >> 
> >>
> >>  So instead of a route to 192.168.1.0/24  a 
> >> default route is 

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Dusan Ilic]

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 
>> noel.kuntze+strongswan-users-ml@thermi.consulting:
>>> Fix your NAT rules.
>>>
>>> Am 30. April 2017 12:28:48 MESZ schrieb Dusan Ilic :
>>>
>>>  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  dev br0  proto static  src 
>>> 10.1.1.1  # LAN passthrough?
>>>  default via 85.24.x.x dev vlan847  proto static  src 10.1.1.1 
>>> 
>>>
>>>  So instead of a route to 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 
>>>  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 
>>> 

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Dusan Ilic]

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 
>> noel.kuntze+strongswan-users-ml@thermi.consulting:
>>> Fix your NAT rules.
>>>
>>> Am 30. April 2017 12:28:48 MESZ schrieb Dusan Ilic :
>>>
>>>  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  dev br0  proto static  src 
>>> 10.1.1.1  # LAN passthrough?
>>>  default via 85.24.x.x dev vlan847  proto static  src 10.1.1.1 
>>> 
>>>
>>>  So instead of a route to 192.168.1.0/24  a 
>>> default route is added, but it
>>>  looks like it doesn't go through the tunnel... 

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Noel Kuntze]

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 
> noel.kuntze+strongswan-users-ml@thermi.consulting:
>> Fix your NAT rules.
>>
>> Am 30. April 2017 12:28:48 MESZ schrieb Dusan Ilic :
>>
>>  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  dev br0  proto static  src 
>> 10.1.1.1  # LAN passthrough?
>>  default via 85.24.x.x dev vlan847  proto static  src 10.1.1.1 
>> 
>>
>>  So instead of a route to 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 
>>  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. 
>> 

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Dusan Ilic]

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.


*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?*



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 
noel.kuntze+strongswan-users-ml@thermi.consulting:

Fix your NAT rules.

Am 30. April 2017 12:28:48 MESZ schrieb Dusan Ilic :

  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  dev br0  proto static  src 10.1.1.1 
 # LAN passthrough?
  default via 85.24.x.x dev vlan847  proto static  src 10.1.1.1 


  So instead of a route to 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 

  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.

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[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 
>>> noel.kuntze+strongswan-users-ml@thermi.consulting:
 Fix your NAT rules.

 Am 30. April 2017 12:28:48 MESZ schrieb Dusan Ilic :

  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  dev br0  proto static  src 10.1.1.1 
  # LAN passthrough?
  default via 85.24.x.x dev vlan847  proto static  src 10.1.1.1 
 

  So instead of a route to 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 
  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 

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Dusan Ilic]

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 
noel.kuntze+strongswan-users-ml@thermi.consulting:

Fix your NAT rules.

Am 30. April 2017 12:28:48 MESZ schrieb Dusan Ilic :

 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  dev br0  proto static  src 10.1.1.1 
 # LAN passthrough?
 default via 85.24.x.x dev vlan847  proto static  src 10.1.1.1 


 So instead of a route to 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 

 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

   

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[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 
> noel.kuntze+strongswan-users-ml@thermi.consulting:
>> Fix your NAT rules.
>>
>> Am 30. April 2017 12:28:48 MESZ schrieb Dusan Ilic :
>>
>> 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  dev br0  proto static  src 10.1.1.1 
>>  # LAN passthrough?
>> default via 85.24.x.x dev vlan847  proto static  src 10.1.1.1 
>> 
>>
>> So instead of a route to 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 
>>  
>> 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  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  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? 
>>
>>

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Dusan Ilic]

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 
noel.kuntze+strongswan-users-ml@thermi.consulting:

Fix your NAT rules.

Am 30. April 2017 12:28:48 MESZ schrieb Dusan Ilic :

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   dev br0  proto static  src10.1.1.1 
  # LAN passthrough?
default via 85.24.x.x dev vlan847  proto static  src10.1.1.1 


So instead of a route to192.168.1.0/24   a default 
route is added, but it
looks like it doesn't go through the tunnel... traffic to192.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 
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 
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

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[noel . kuntze+strongswan-users-ml]

Fix your NAT rules.

Am 30. April 2017 12:28:48 MESZ schrieb Dusan Ilic :
>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 dev br0  proto static  src 10.1.1.1 # LAN passthrough?
>default via 85.24.x.x dev vlan847  proto static  src 10.1.1.1
>
>So instead of a route to 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 
>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 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 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
>> Users@lists.strongswan.org
>> https://lists.strongswan.org/mailman/listinfo/users

Sent from mobile___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Dusan Ilic]

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 dev br0  proto static  src 10.1.1.1 # LAN passthrough?
default via 85.24.x.x dev vlan847  proto static  src 10.1.1.1

So instead of a route to 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 
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 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 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
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users


___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[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 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 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




signature.asc
Description: OpenPGP digital signature
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Dusan Ilic]

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.


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).


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

Log when remote side initiates connection:
Apr 29 16:32:20 R6250 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 charon: 10[CFG] no matching peer config found

It looks like the same issue, the remote endpoint doesnt send the configured ID?

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?

Den 2017-04-29 kl. 17:28, skrev Noel Kuntze:

I just tested it with two hosts running strongSwan 5.5.2 and it works just fine.
This is a problem with the fortigate, which resolves its configured ID to an IP 
address.
Try to find a way to turn that off.

Here are the two configurations I used (one with ipsec.conf, one with 
swanctl.conf). They are functionally identical.

Instead of starting the FQDN in "left" or "right", you can also set "leftallowany" and 
"rightallowany2".
There are no such options for swanctl, so adding 0.0.0.0/0 and ::/0 to left and 
right allows any. It behaves identical.

--- configurations ---

--- legacy ipsec.conf format ---

--- on vms.thermicorp.lan ---

--- ipsec.conf ---
conn vms-test
 left = %vms.thermicorp.lan
 leftid = vms.thermicorp.lan
 leftauth = psk
 leftsubnet = 172.16.0.2
 right = %thermi-pc.thermicorp.lan
 rightid = thermi-pc.thermicorp.lan
 rightauth = psk
 rightsubnet = 172.16.0.1
 ike = chacha20poly1305-prfsha256-newhope128
 esp = chacha20poly1305-newhope128, chacha20poly1305
 keyexchange = ikev2
 auto = add

--- ipsec.secrets ---

thermi-pc.thermicorp.lan : PSK test123

--- on thermi-pc.thermicorp.lan ---

None, used equivalent swanctl.conf configuration.
You could just use the configuration from vms.thermicorp.lan, because the peer 
could figure out
that his side is "right" now, when the FQDN defined in "right" resolves to a 
local IP.

--- modern swanctl.conf format ---

--- on vms.thermicorp.lan ---

--- swanctl.conf ---

connections {
 vms-test {
 version = 2
 remote_addrs = thermi-pc.thermicorp.lan
 local_addrs = vms.thermicorp.lan
 local {
 auth = psk
 id = vms.thermicorp.lan
 }
 remote {
 auth = psk
 id = thermi-pc.thermicorp.lan
 }
 children {
 vms-test-esp {
 local_ts = 172.16.0.2
 remote_ts = 172.16.0.1
 esp_proposals = chacha20poly1305-newhope128, 
chacha20poly1305
 }
 }
 }
}

secrets {
 ike-vms-test {
 id = thermi-pc.thermicorp.lan
 secret = test123
 }
}

--- on thermi-pc.thermicorp.lan ---

--- swanctl.conf ---

connections {
 vms-test {
 version = 2
 local_addrs = thermi-pc.thermicorp.lan, %any
 remote_addrs = vms.thermicorp.lan, %any
 proposals = chacha20poly1305-prfsha256-newhope128
 local {
 auth = psk
 id = thermi-pc.thermicorp.lan
 }
 remote {
 auth = psk
 id = vms.thermicorp.lan
 }
 children {
 vms-test-esp {
 local_ts = 172.16.0.1
 remote_ts = 172.16.0.2
 esp_proposals = chacha20poly1305-newhope128, 
chacha20poly1305
 }
 }
 }
}

secrets {
 ike-vms-test {
 id = vms.thermicorp.lan
 secret = test123
 }
}


--- Logs ---

Attached.


On 29.04.2017 14:29, Dusan Ilic wrote:

For the Fortigate connection if I add in both locla 

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Noel Kuntze]

I just tested it with two hosts running strongSwan 5.5.2 and it works just fine.
This is a problem with the fortigate, which resolves its configured ID to an IP 
address.
Try to find a way to turn that off.

Here are the two configurations I used (one with ipsec.conf, one with 
swanctl.conf). They are functionally identical.

Instead of starting the FQDN in "left" or "right", you can also set 
"leftallowany" and "rightallowany2".
There are no such options for swanctl, so adding 0.0.0.0/0 and ::/0 to left and 
right allows any. It behaves identical.

--- configurations ---

--- legacy ipsec.conf format ---

--- on vms.thermicorp.lan ---

--- ipsec.conf ---
conn vms-test
left = %vms.thermicorp.lan
leftid = vms.thermicorp.lan
leftauth = psk
leftsubnet = 172.16.0.2
right = %thermi-pc.thermicorp.lan
rightid = thermi-pc.thermicorp.lan
rightauth = psk
rightsubnet = 172.16.0.1
ike = chacha20poly1305-prfsha256-newhope128
esp = chacha20poly1305-newhope128, chacha20poly1305
keyexchange = ikev2
auto = add

--- ipsec.secrets ---

thermi-pc.thermicorp.lan : PSK test123

--- on thermi-pc.thermicorp.lan ---

None, used equivalent swanctl.conf configuration.
You could just use the configuration from vms.thermicorp.lan, because the peer 
could figure out
that his side is "right" now, when the FQDN defined in "right" resolves to a 
local IP.

--- modern swanctl.conf format ---

--- on vms.thermicorp.lan ---

--- swanctl.conf ---

connections {
vms-test {
version = 2
remote_addrs = thermi-pc.thermicorp.lan
local_addrs = vms.thermicorp.lan
local {
auth = psk
id = vms.thermicorp.lan
}
remote {
auth = psk
id = thermi-pc.thermicorp.lan
}
children {
vms-test-esp {
local_ts = 172.16.0.2
remote_ts = 172.16.0.1
esp_proposals = chacha20poly1305-newhope128, 
chacha20poly1305
}
}
}
}

secrets {
ike-vms-test {
id = thermi-pc.thermicorp.lan
secret = test123
}
}

--- on thermi-pc.thermicorp.lan ---

--- swanctl.conf ---

connections {
vms-test {
version = 2
local_addrs = thermi-pc.thermicorp.lan, %any
remote_addrs = vms.thermicorp.lan, %any
proposals = chacha20poly1305-prfsha256-newhope128
local {
auth = psk
id = thermi-pc.thermicorp.lan
}
remote {
auth = psk
id = vms.thermicorp.lan
}
children {
vms-test-esp {
local_ts = 172.16.0.1
remote_ts = 172.16.0.2
esp_proposals = chacha20poly1305-newhope128, 
chacha20poly1305
}
}
}
}

secrets {
ike-vms-test {
id = vms.thermicorp.lan
secret = test123
}
}


--- Logs ---

Attached.


On 29.04.2017 14:29, Dusan Ilic wrote:
>
> For the Fortigate connection if I add in both locla and remote ID, instead of 
> only remote ID, i get the following:
>
> authentication of '85.230.x.x' with pre-shared key successful
> constraint check failed: identity 'remote.example' required
> selected peer config 'site2site' inacceptable: constraint checking failed
> no alternative config found
>
> Only remote ID as you suggested
>
> parsed IKE_AUTH response 1 [ IDr AUTH SA TSi TSr ]
> no shared key found for 'local.example' - '85.230.x.x'
> generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
>
>
> Den 2017-04-29 kl. 13:26, skrev Dusan Ilic:
>>
>> no shared key found for 'local.example' - '137.135.x.x'
>> generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
>>
>> The remote side is a Fortigate firewall, so I can't configure it the same. I 
>> can just choose local interface (ie wan) and remote gateway IP or Dynamic 
>> DNS, I have chosen Dynamic DNS.
>> It logs "peer SA proposal not match local policy".
>>
>> If I change to IP adresses it works, but that won't work for very long 
>> unfortunately.
>>
>>
>> Den 2017-04-29 kl. 02:49, skrev Noel Kuntze:
>>> Hello Dusan,
>>>
>>> On 29.04.2017 02:25, Dusan Ilic wrote:
 Hi Noel,

 Okey, if I don't set "left" and initiate the connection it takes the wrong 
 route (multiple WAN-interfaces) and the remote peer don't expect that 
 source IP. Probably works better if the remote peer is initiating 
 connection instead.

 If I set "left=%local.example" and "right" 

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Dusan Ilic]

For the Fortigate connection if I add in both locla and remote ID, 
instead of only remote ID, i get the following:


authentication of '85.230.x.x' with pre-shared key successful
constraint check failed: identity 'remote.example' required
selected peer config 'site2site' inacceptable: constraint checking failed
no alternative config found

Only remote ID as you suggested

parsed IKE_AUTH response 1 [ IDr AUTH SA TSi TSr ]
no shared key found for 'local.example' - '85.230.x.x'
generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]


Den 2017-04-29 kl. 13:26, skrev Dusan Ilic:


no shared key found for 'local.example' - '137.135.x.x'
generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]

The remote side is a Fortigate firewall, so I can't configure it the 
same. I can just choose local interface (ie wan) and remote gateway IP 
or Dynamic DNS, I have chosen Dynamic DNS.

It logs "peer SA proposal not match local policy".

If I change to IP adresses it works, but that won't work for very long 
unfortunately.



Den 2017-04-29 kl. 02:49, skrev Noel Kuntze:

Hello Dusan,

On 29.04.2017 02:25, Dusan Ilic wrote:

Hi Noel,

Okey, if I don't set "left" and initiate the connection it takes the wrong 
route (multiple WAN-interfaces) and the remote peer don't expect that source IP. Probably 
works better if the remote peer is initiating connection instead.

If I set "left=%local.example" and "right" / "rightid" as you suggest I get the 
following output n logfile:

Apr 29 00:10:51 R6250 daemon.info charon: 10[IKE] tried 1 shared key for 
'local.example' - '137.135.x.x', but MAC mismatched
Apr 29 00:10:51 R6250 daemon.info charon: 10[ENC] generating INFORMATIONAL 
request 2 [ N(AUTH_FAILED) ]

If i fiddle in ipsec.secrets a bit, i get this instead:

authentication of '137.135.x.x' with pre-shared key successful
constraint check failed: identity 'remote.example' required
selected peer config 'site2site' inacceptable: constraint checking failed
no alternative config found


Alright. Try the following
left=%local.example
leftid=local.example
right=%remote.example
rightid=remote.example

remote.example : PSK "PSKGOESHERE"

Do it vice versa on the remote peer.

Kind regards,
Noel





___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Dusan Ilic]

I also tried with another remote endpoint with Strongswan too, and 
reversed the config.


parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]
received AUTHENTICATION_FAILED notify error


Den 2017-04-29 kl. 13:26, skrev Dusan Ilic:


no shared key found for 'local.example' - '137.135.x.x'
generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]

The remote side is a Fortigate firewall, so I can't configure it the 
same. I can just choose local interface (ie wan) and remote gateway IP 
or Dynamic DNS, I have chosen Dynamic DNS.

It logs "peer SA proposal not match local policy".

If I change to IP adresses it works, but that won't work for very long 
unfortunately.



Den 2017-04-29 kl. 02:49, skrev Noel Kuntze:

Hello Dusan,

On 29.04.2017 02:25, Dusan Ilic wrote:

Hi Noel,

Okey, if I don't set "left" and initiate the connection it takes the wrong 
route (multiple WAN-interfaces) and the remote peer don't expect that source IP. Probably 
works better if the remote peer is initiating connection instead.

If I set "left=%local.example" and "right" / "rightid" as you suggest I get the 
following output n logfile:

Apr 29 00:10:51 R6250 daemon.info charon: 10[IKE] tried 1 shared key for 
'local.example' - '137.135.x.x', but MAC mismatched
Apr 29 00:10:51 R6250 daemon.info charon: 10[ENC] generating INFORMATIONAL 
request 2 [ N(AUTH_FAILED) ]

If i fiddle in ipsec.secrets a bit, i get this instead:

authentication of '137.135.x.x' with pre-shared key successful
constraint check failed: identity 'remote.example' required
selected peer config 'site2site' inacceptable: constraint checking failed
no alternative config found


Alright. Try the following
left=%local.example
leftid=local.example
right=%remote.example
rightid=remote.example

remote.example : PSK "PSKGOESHERE"

Do it vice versa on the remote peer.

Kind regards,
Noel





___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users


___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Dusan Ilic]

no shared key found for 'local.example' - '137.135.x.x'
generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]

The remote side is a Fortigate firewall, so I can't configure it the 
same. I can just choose local interface (ie wan) and remote gateway IP 
or Dynamic DNS, I have chosen Dynamic DNS.

It logs "peer SA proposal not match local policy".

If I change to IP adresses it works, but that won't work for very long 
unfortunately.



Den 2017-04-29 kl. 02:49, skrev Noel Kuntze:

Hello Dusan,

On 29.04.2017 02:25, Dusan Ilic wrote:

Hi Noel,

Okey, if I don't set "left" and initiate the connection it takes the wrong 
route (multiple WAN-interfaces) and the remote peer don't expect that source IP. Probably 
works better if the remote peer is initiating connection instead.

If I set "left=%local.example" and "right" / "rightid" as you suggest I get the 
following output n logfile:

Apr 29 00:10:51 R6250 daemon.info charon: 10[IKE] tried 1 shared key for 
'local.example' - '137.135.x.x', but MAC mismatched
Apr 29 00:10:51 R6250 daemon.info charon: 10[ENC] generating INFORMATIONAL 
request 2 [ N(AUTH_FAILED) ]

If i fiddle in ipsec.secrets a bit, i get this instead:

authentication of '137.135.x.x' with pre-shared key successful
constraint check failed: identity 'remote.example' required
selected peer config 'site2site' inacceptable: constraint checking failed
no alternative config found


Alright. Try the following
left=%local.example
leftid=local.example
right=%remote.example
rightid=remote.example

remote.example : PSK "PSKGOESHERE"

Do it vice versa on the remote peer.

Kind regards,
Noel



___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Noel Kuntze]

Hello Dusan,

On 29.04.2017 02:25, Dusan Ilic wrote:
> Hi Noel,
>
> Okey, if I don't set "left" and initiate the connection it takes the wrong 
> route (multiple WAN-interfaces) and the remote peer don't expect that source 
> IP. Probably works better if the remote peer is initiating connection instead.
>
> If I set "left=%local.example" and "right" / "rightid" as you suggest I get 
> the following output n logfile:
>
> Apr 29 00:10:51 R6250 daemon.info charon: 10[IKE] tried 1 shared key for 
> 'local.example' - '137.135.x.x', but MAC mismatched
> Apr 29 00:10:51 R6250 daemon.info charon: 10[ENC] generating INFORMATIONAL 
> request 2 [ N(AUTH_FAILED) ]
>
> If i fiddle in ipsec.secrets a bit, i get this instead:
>
> authentication of '137.135.x.x' with pre-shared key successful
> constraint check failed: identity 'remote.example' required
> selected peer config 'site2site' inacceptable: constraint checking failed
> no alternative config found
>
Alright. Try the following
left=%local.example
leftid=local.example
right=%remote.example
rightid=remote.example

remote.example : PSK "PSKGOESHERE"

Do it vice versa on the remote peer.

Kind regards,
Noel



signature.asc
Description: OpenPGP digital signature
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Dusan Ilic]

Hi Noel,

Okey, if I don't set "left" and initiate the connection it takes the 
wrong route (multiple WAN-interfaces) and the remote peer don't expect 
that source IP. Probably works better if the remote peer is initiating 
connection instead.


If I set "left=%local.example" and "right" / "rightid" as you suggest I 
get the following output n logfile:


Apr 29 00:10:51 R6250 daemon.info charon: 10[IKE] tried 1 shared key for 
'local.example' - '137.135.x.x', but MAC mismatched
Apr 29 00:10:51 R6250 daemon.info charon: 10[ENC] generating 
INFORMATIONAL request 2 [ N(AUTH_FAILED) ]


If i fiddle in ipsec.secrets a bit, i get this instead:

authentication of '137.135.x.x' with pre-shared key successful
constraint check failed: identity 'remote.example' required
selected peer config 'site2site' inacceptable: constraint checking failed
no alternative config found

When remote peer tries to connect instead:


Apr 29 00:08:44 R6250 daemon.info charon: 06[CFG] looking for peer 
configs matching 85.24.x.x[%any]...137.135.x.x[137.135.x.x]

Apr 29 00:08:44 R6250 daemon.info charon: 06[CFG] selected peer config 'vpn'
Apr 29 00:08:44 R6250 daemon.info charon: 06[IKE] no shared key found 
for '%any' - '137.135.x.x'


Config 'vpn' is a completely different connection definition.


Den 2017-04-28 kl. 16:48, skrev Noel Kuntze:

Hello Dusan,

Don't set "left".
Set "right=%remoteDNSname" and "rightid="remoteDNSname". Use the following verbatim as 
selector "remoteDNSname". DO NOT use %remoteDNSname".
Secrets are looked up based on the remote peer's ID, not the local one's. 
There's no need to use IPs as IDs with IKEv2. The IDs can be read from the
packets without looking up the secret first and decrypting the packet..

It doesn't matter if the local peer has a changing IP, unless you restrict 
IKE_SAs by the source IP, which you don't have to do at all and just
gives you more problems unless you really know what you're doing.

Kind regards,
Noel

On 28.04.2017 10:03, Dusan Ilic wrote:

Here is another example (dynamic DNS both sides), other side is initiating.


Apr 28 07:49:06 R6250 daemon.info charon: 12[IKE] x.x.x.200 is initiating an 
IKE_SA
Apr 28 07:49:06 R6250 authpriv.info charon: 12[IKE] x.x.x.200 is initiating an 
IKE_SA
Apr 28 07:49:06 R6250 daemon.info charon: 12[IKE] sending cert request for "C=US, 
O=Let's Encrypt, CN=Let's Encrypt Authority X3"
Apr 28 07:49:06 R6250 daemon.info charon: 12[ENC] generating IKE_SA_INIT 
response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(MULT_AUTH) ]
Apr 28 07:49:06 R6250 daemon.info charon: 12[NET] sending packet: from 
x.x.x.96[500] to x.x.x.200[500] (337 bytes)
Apr 28 07:49:06 R6250 daemon.info charon: 15[NET] received packet: from 
x.x.x.200[500] to x.x.x.96[500] (220 bytes)
Apr 28 07:49:06 R6250 daemon.info charon: 15[ENC] parsed IKE_AUTH request 1 [ 
IDi N(INIT_CONTACT) AUTH N(MSG_ID_SYN_SUP) SA TSi TSr ]
Apr 28 07:49:06 R6250 daemon.info charon: 15[CFG] looking for peer configs 
matching x.x.x.96[%any]...x.x.x.200[x.x.x.200]
Apr 28 07:49:06 R6250 daemon.info charon: 15[CFG] selected peer config 'VPN'
Apr 28 07:49:06 R6250 daemon.info charon: 15[IKE] no shared key found for 
'%any' - 'x.x.x.200'
Apr 28 07:49:06 R6250 daemon.info charon: 15[ENC] generating IKE_AUTH response 
1 [ N(AUTH_FAILED) ]
Apr 28 07:49:06 R6250 daemon.info charon: 15[NET] sending packet: from 
x.x.x.96[500] to x.x.x.200[500] (76 bytes)

Peer config is the wrong one, below is the config and IPsec secrets

conn test
 keylife=3600s
 ikelifetime=28800s
 left=%local.net
 leftsubnet=10.1.1.0/26
 right=%remote.net
 rightsubnet=192.168.18.0/24,10.0.0.0/24
 ike=aes128-sha1-modp1024
 esp=aes128-sha1-modp1024

IPsec secret

%local.net %remote.net : PSK "XXX"

In my understanding from the Strongswan documentation, if hostname is prefixed with 
"%" it will do a DNS-lookup and use those IP-adresses?





___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Noel Kuntze]

Hello Dusan,

Don't set "left".
Set "right=%remoteDNSname" and "rightid="remoteDNSname". Use the following 
verbatim as selector "remoteDNSname". DO NOT use %remoteDNSname".
Secrets are looked up based on the remote peer's ID, not the local one's. 
There's no need to use IPs as IDs with IKEv2. The IDs can be read from the
packets without looking up the secret first and decrypting the packet..

It doesn't matter if the local peer has a changing IP, unless you restrict 
IKE_SAs by the source IP, which you don't have to do at all and just
gives you more problems unless you really know what you're doing.

Kind regards,
Noel

On 28.04.2017 10:03, Dusan Ilic wrote:
>
> Here is another example (dynamic DNS both sides), other side is initiating.
>
>
> Apr 28 07:49:06 R6250 daemon.info charon: 12[IKE] x.x.x.200 is initiating an 
> IKE_SA
> Apr 28 07:49:06 R6250 authpriv.info charon: 12[IKE] x.x.x.200 is initiating 
> an IKE_SA
> Apr 28 07:49:06 R6250 daemon.info charon: 12[IKE] sending cert request for 
> "C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3"
> Apr 28 07:49:06 R6250 daemon.info charon: 12[ENC] generating IKE_SA_INIT 
> response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(MULT_AUTH) ]
> Apr 28 07:49:06 R6250 daemon.info charon: 12[NET] sending packet: from 
> x.x.x.96[500] to x.x.x.200[500] (337 bytes)
> Apr 28 07:49:06 R6250 daemon.info charon: 15[NET] received packet: from 
> x.x.x.200[500] to x.x.x.96[500] (220 bytes)
> Apr 28 07:49:06 R6250 daemon.info charon: 15[ENC] parsed IKE_AUTH request 1 [ 
> IDi N(INIT_CONTACT) AUTH N(MSG_ID_SYN_SUP) SA TSi TSr ]
> Apr 28 07:49:06 R6250 daemon.info charon: 15[CFG] looking for peer configs 
> matching x.x.x.96[%any]...x.x.x.200[x.x.x.200]
> Apr 28 07:49:06 R6250 daemon.info charon: 15[CFG] selected peer config 'VPN'
> Apr 28 07:49:06 R6250 daemon.info charon: 15[IKE] no shared key found for 
> '%any' - 'x.x.x.200'
> Apr 28 07:49:06 R6250 daemon.info charon: 15[ENC] generating IKE_AUTH 
> response 1 [ N(AUTH_FAILED) ]
> Apr 28 07:49:06 R6250 daemon.info charon: 15[NET] sending packet: from 
> x.x.x.96[500] to x.x.x.200[500] (76 bytes)
>
> Peer config is the wrong one, below is the config and IPsec secrets
>
> conn test
> keylife=3600s
> ikelifetime=28800s
> left=%local.net
> leftsubnet=10.1.1.0/26
> right=%remote.net
> rightsubnet=192.168.18.0/24,10.0.0.0/24
> ike=aes128-sha1-modp1024
> esp=aes128-sha1-modp1024
>
> IPsec secret
>
> %local.net %remote.net : PSK "XXX"
>
> In my understanding from the Strongswan documentation, if hostname is 
> prefixed with "%" it will do a DNS-lookup and use those IP-adresses?
>




signature.asc
Description: OpenPGP digital signature
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Dusan Ilic]

Here is another example (dynamic DNS both sides), other side is initiating.


Apr 28 07:49:06 R6250 daemon.info charon: 12[IKE] x.x.x.200 is 
initiating an IKE_SA
Apr 28 07:49:06 R6250 authpriv.info charon: 12[IKE] x.x.x.200 is 
initiating an IKE_SA
Apr 28 07:49:06 R6250 daemon.info charon: 12[IKE] sending cert request 
for "C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3"
Apr 28 07:49:06 R6250 daemon.info charon: 12[ENC] generating IKE_SA_INIT 
response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(MULT_AUTH) ]
Apr 28 07:49:06 R6250 daemon.info charon: 12[NET] sending packet: from 
x.x.x.96[500] to x.x.x.200[500] (337 bytes)
Apr 28 07:49:06 R6250 daemon.info charon: 15[NET] received packet: from 
x.x.x.200[500] to x.x.x.96[500] (220 bytes)
Apr 28 07:49:06 R6250 daemon.info charon: 15[ENC] parsed IKE_AUTH 
request 1 [ IDi N(INIT_CONTACT) AUTH N(MSG_ID_SYN_SUP) SA TSi TSr ]
Apr 28 07:49:06 R6250 daemon.info charon: 15[CFG] looking for peer 
configs matching x.x.x.96[%any]...x.x.x.200[x.x.x.200]

Apr 28 07:49:06 R6250 daemon.info charon: 15[CFG] selected peer config 'VPN'
Apr 28 07:49:06 R6250 daemon.info charon: 15[IKE] no shared key found 
for '%any' - 'x.x.x.200'
Apr 28 07:49:06 R6250 daemon.info charon: 15[ENC] generating IKE_AUTH 
response 1 [ N(AUTH_FAILED) ]
Apr 28 07:49:06 R6250 daemon.info charon: 15[NET] sending packet: from 
x.x.x.96[500] to x.x.x.200[500] (76 bytes)


Peer config is the wrong one, below is the config and IPsec secrets

conn test
keylife=3600s
ikelifetime=28800s
left=%local.net
leftsubnet=10.1.1.0/26
right=%remote.net
rightsubnet=192.168.18.0/24,10.0.0.0/24
ike=aes128-sha1-modp1024
esp=aes128-sha1-modp1024

IPsec secret

%local.net %remote.net : PSK "XXX"

In my understanding from the Strongswan documentation, if hostname is 
prefixed with "%" it will do a DNS-lookup and use those IP-adresses?



Den 2017-04-28 kl. 08:08, skrev Dusan Ilic:


Thank you

Well for starters, I can paste the logs i had in an earlier thread. 
Are you saying that site-2-site with PSK must use certificates when 
using dynamic hostnames?
What about if only one side of the tunnel has a dynamic IP and 
dynamic DNS (my side)? I have two remote peers, one using dynamic 
hostname (Fortigate, supports dynamic hostnames for remote peer in 
GUI configuration) and one with static IP (UniFi gateway, using 
Strongswan)


left=%hostname is working for one of my tunnels below, but not the 
other. See

below.

The working:
sending cert request for "C=US, O=Let's Encrypt, CN=Let's Encrypt
Authority X3"
authentication of 'hostname' (myself) with pre-shared key
establishing CHILD_SA Azure
generating IKE_AUTH request 1 [ IDi CERTREQ IDr AUTH SA TSi TSr
N(EAP_ONLY) ]
sending packet: from 85.24 .x.x[500] to 137.135 
.x.x[500] (380 bytes)
received packet: from 137.135 .x.x[500] to 85.24 
.x.x[500] (204 bytes)

parsed IKE_AUTH response 1 [ IDr AUTH SA TSi TSr ]
authentication of '137.135 .x.x' with pre-shared key 
successful

IKE_SA Azure[2] established between
85.24 .x.x[hostname]...137.135.x.x[137.135.x.x]
scheduling reauthentication in 27923 s
maximum IKE_SA lifetime 28463 s
connection 'Azure' established successfully

The non-working:
sending cert request for "C=US, O=Let's Encrypt, CN=Let's Encrypt
Authority X3"
authentication of 'hostname' (myself) with pre-shared key
establishing CHILD_SA Wesafe
generating IKE_AUTH request 1 [ IDi CERTREQ IDr AUTH SA TSi TSr
N(MULT_AUTH) N(EAP_ONLY) ]
sending packet: from 85.24 .x.x[500] to 94.254 
.x.x[500] (380 bytes)
received packet: from 94.254 .x.x[500] to 85.24 
.x.x[500] (76 bytes)

parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]
received AUTHENTICATION_FAILED notify error
establishing connection 'Wesafe' failed

ipsec.secrets 
%hostname 137.135 .x.x : PSK ""
%hostname 94.254 .x.x : PSK "x"

"hostname" is my side of the tunnel and is a dynamic DNS hostname 
resolving to my public IP.



Den 2017-04-27 kl. 22:57, skrev Noel Kuntze:

On 27.04.2017 22:38, Dusan Ilic wrote:

I would really appreciate some help with below also, Im having a Hard time 
understanding how Strongswan chooses connection definitions and ipsec secrets.

Based on IPs, identities and authentication methods.

For example, how can I setup an ikev2 psk tunnel between two hosts with dynamic 
dns?

Look at the "site-2-dynamic-ip" example at the UsableExamples page[1] for a 
configuration that uses
certificates for authentication. Read the text at the beginning of the page.

Can I have several ip secrets or connections with %any?

No. One secret per identity.

Ive tried with %dyndns but seem to get some errors about constraints and such. 
If someone would give me an explanation that would be great!

You need to paste logs to get help.

[1]https://wiki.strongswan.org/projects/strongswan/wiki/UsableExamples#Site-To-Site-Scenario







___
Users mailing list

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Dusan Ilic]

Thank you

Well for starters, I can paste the logs i had in an earlier thread. Are 
you saying that site-2-site with PSK must use certificates when using 
dynamic hostnames?
What about if only one side of the tunnel has a dynamic IP and dynamic 
DNS (my side)? I have two remote peers, one using dynamic hostname 
(Fortigate, supports dynamic hostnames for remote peer in GUI 
configuration) and one with static IP (UniFi gateway, using Strongswan)


left=%hostname is working for one of my tunnels below, but not the 
other. See

below.

The working:
sending cert request for "C=US, O=Let's Encrypt, CN=Let's Encrypt
Authority X3"
authentication of 'hostname' (myself) with pre-shared key
establishing CHILD_SA Azure
generating IKE_AUTH request 1 [ IDi CERTREQ IDr AUTH SA TSi TSr
N(EAP_ONLY) ]
sending packet: from 85.24 .x.x[500] to 137.135 
.x.x[500] (380 bytes)
received packet: from 137.135 .x.x[500] to 85.24 
.x.x[500] (204 bytes)

parsed IKE_AUTH response 1 [ IDr AUTH SA TSi TSr ]
authentication of '137.135 .x.x' with pre-shared key successful
IKE_SA Azure[2] established between
85.24 .x.x[hostname]...137.135.x.x[137.135.x.x]
scheduling reauthentication in 27923 s
maximum IKE_SA lifetime 28463 s
connection 'Azure' established successfully

The non-working:
sending cert request for "C=US, O=Let's Encrypt, CN=Let's Encrypt
Authority X3"
authentication of 'hostname' (myself) with pre-shared key
establishing CHILD_SA Wesafe
generating IKE_AUTH request 1 [ IDi CERTREQ IDr AUTH SA TSi TSr
N(MULT_AUTH) N(EAP_ONLY) ]
sending packet: from 85.24 .x.x[500] to 94.254 
.x.x[500] (380 bytes)
received packet: from 94.254 .x.x[500] to 85.24 
.x.x[500] (76 bytes)

parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]
received AUTHENTICATION_FAILED notify error
establishing connection 'Wesafe' failed

ipsec.secrets 
%hostname 137.135 .x.x : PSK ""
%hostname 94.254 .x.x : PSK "x"

"hostname" is my side of the tunnel and is a dynamic DNS hostname 
resolving to my public IP.



Den 2017-04-27 kl. 22:57, skrev Noel Kuntze:


On 27.04.2017 22:38, Dusan Ilic wrote:

I would really appreciate some help with below also, Im having a Hard time 
understanding how Strongswan chooses connection definitions and ipsec secrets.

Based on IPs, identities and authentication methods.

For example, how can I setup an ikev2 psk tunnel between two hosts with dynamic 
dns?

Look at the "site-2-dynamic-ip" example at the UsableExamples page[1] for a 
configuration that uses
certificates for authentication. Read the text at the beginning of the page.

Can I have several ip secrets or connections with %any?

No. One secret per identity.

Ive tried with %dyndns but seem to get some errors about constraints and such. 
If someone would give me an explanation that would be great!

You need to paste logs to get help.

[1]https://wiki.strongswan.org/projects/strongswan/wiki/UsableExamples#Site-To-Site-Scenario



___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Noel Kuntze]

On 27.04.2017 22:38, Dusan Ilic wrote:
> I would really appreciate some help with below also, Im having a Hard time 
> understanding how Strongswan chooses connection definitions and ipsec secrets.
Based on IPs, identities and authentication methods.
>
> For example, how can I setup an ikev2 psk tunnel between two hosts with 
> dynamic dns?
Look at the "site-2-dynamic-ip" example at the UsableExamples page[1] for a 
configuration that uses
certificates for authentication. Read the text at the beginning of the page.
> Can I have several ip secrets or connections with %any?
No. One secret per identity.
>
> Ive tried with %dyndns but seem to get some errors about constraints and 
> such. If someone would give me an explanation that would be great!
You need to paste logs to get help.

[1]https://wiki.strongswan.org/projects/strongswan/wiki/UsableExamples#Site-To-Site-Scenario



signature.asc
Description: OpenPGP digital signature
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Dusan Ilic]

I would really appreciate some help with below also, Im having a Hard 
time understanding how Strongswan chooses connection definitions and 
ipsec secrets.


For example, how can I setup an ikev2 psk tunnel between two hosts with 
dynamic dns?

Can I have several ip secrets or connections with %any?

Ive tried with %dyndns but seem to get some errors about constraints and 
such. If someone would give me an explanation that would be great!



Den 2017-04-24 kl. 18:48, skrev Dusan Ilic:

No one?


Den 2017-04-21 kl. 10:16, skrev Dusan Ilic:

Hi!

I have some issues, please read on.

1. I have one side of the IP-sec tunnel with dynamic IP (associated 
with a dynamic hostname), I would like not need to change the 
"left"-parameter in both ipsec.conf and ipsec.secrets whenever the 
local WAN IP changes, so I have tried putting "left = %any" or "left 
= %hostname". Now, with %hostname (preferable) it wont connect, but 
with %any it does connect, sometimes. I can see in the documentation 
that %any does a local root lookup if the local host is initiating 
the connection, but only accepting all local IP-adresses if it 
responds to the remote peer initiation. In my case ths always work 
when the remote peer is initiating the connection, but if my local 
end initiates it (ie start=route) it seem to choose the wrong public 
source IP to connect from.
In my case, my local gateway running Strongswan have multiple public 
interfaces (but only one should be used for IP-sec tunnels), se below 
route information:


default
nexthop via 90.225.x.x  dev vlan845 weight 1
nexthop via 10.248.x.x  dev ppp0 weight 256
nexthop via 85.24.x.x  dev vlan847 weight 1
nexthop via 46.195.x.x  dev ppp1 weight 1

My gateway is configured to use 10.248.0.x as "default route" 
(highest weight/priority), but when Strongswan tried to initiate the 
tunnel it seems to always default too the last route, 46.195.x.x, and 
this wont work as the remote peer is expecting 85.24.x.x. Now, is 
there a way to tell Strongswan to use this IP/interface? I hope 
"left=%hostname" would work, because the hostname is dynamically 
ponting to the IP at interface vlan847, but as already stated this 
isn't working either.


Any suggestions?

2. Probably also cause by the above routing setup (wild guess), I 
also have IKEv2 EAP roadwarrior connectin in Strongswan on the same 
interface. The Strongswan client on Android connects to my public 
hostname, and everything works (and in this setup I can have 
left=%hostname on the server), it's a full tunnel with 
leftsubnet=0.0.0.0/0. However, all VPN-clients are beeing routed out 
on this same interface the connect to, so the third route above is 
being automatically used (vlan847) instead of the second route on 
ppp0 (with higher weight/priority). Locally connected clients to the 
gateway all gets routed out on ppp0, but not VPN-clients. Why is 
this, and what can be done to correct this? The reason for me wanting 
the VPN clients connecting on vlan847 also routed on the the Internet 
on ppp0 is simple, ppp0 is a VPN connection from the gateway out to 
the Internet.


I can add that in strongswan.conf I have changed so that all 
VPN-routes added by Strongswan is done in the standard, main routing 
table (instead of 220), so technically the VPN-clients should be 
routed the same as the local clients by the gateway.




___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Dusan Ilic]

I tried something like this, so that only the VPN-client subnet are 
marked differently from ordinary traffic on vlan847, but it doesn't seem 
to work.


iptables -t mangle -I PREROUTING -s VPN-clientIP -i vlan847 -m policy 
--dir in --pol ipsec --proto esp -j M

ARK --set-mark 0x200/0xf00

Below is the rule that I would like to reference, cause this rule uses 
the correct WAN-interface.

122:from all fwmark 0x200/0xf00 lookup WAN2

Den 2017-04-26 kl. 23:19, skrev Noel Kuntze:

Hello Dusan,

In general, charon does not route any packets of the kernel. Charon is out of 
the loop there,
however, it installs routes into routing table 220 by default to make sure the 
packets
that are going to be protected with IPsec reach the remote subnet.
This means that when charon picks the wrong route, the traffic that is 
forwarded or
sent by the kernel to the remote subnet is going to be routed over the last 
fitting route that
the kernel-netlink plugin finds, as Tobias wrote.

In order to prevent this from happening, you have to disable the installation 
of routes.
You do this by setting "charon.install_routes" to "no" in strongswan.conf or try
to set charon.plugins.kernel-netlink.fwmark to a mark value you don't use.

Kind regards,
Noel

On 26.04.2017 22:23, Dusan Ilic wrote:

Hi  again Tobias,

After reading your post once more I suspect we are talking about different 
things. I see you qouted my question why the last multipath is being chosen by 
Strongswan when configuring left=%any and initiating the connection, however Im 
talking about the route Strongswan chooses to forward remote clients out on the 
Internet. Do you think the problem is the same? My remote clients are 
connecting to Public IP on vlsn847, and when accessing the internet 
(leftsubnet=0.0.0.0/0) they are being always routed out the same interface, 
that is vlsn847. What I expect is that Strongswan will hand over the vpn 
clients traffic to the Linux kernel, which will do a normal route lookup and 
route the clients out on interface ppp0. Isnt this possible? Is it maybe 
something in Strongswan that makes it forward incoming traffic out on the 
Internet through the same interface?

 Tobias Brunner skrev 

Hi Dusan,


default
  nexthop via 90.225 .x.x  dev vlan845 weight 1
  nexthop via 10.248 .x.x  dev ppp0 weight 256
  nexthop via 85.24 .x.x  dev vlan847 weight 1
  nexthop via 46.195 .x.x  dev ppp1 weight 1

My gateway is configured to use 10.248.0 .x as "default route" 
(highest
weight/priority), but when Strongswan tried to initiate the tunnel it
seems to always default too the last route, 46.195 .x.x, and this 
wont
work as the remote peer is expecting 85.24 .x.x.

These kinds of multipath routes (via RTA_MULTIPATH) are currently not
supported by strongSwan when looking up source addresses/nexthops.  The
kernel-netlink plugin only sees one of these via RTA_GATEWAY and
RTA_OIF.  You could try to switch to the kernel's default route lookup
by setting either charon.install_routes=no (disables route installation
by strongSwan altogether, only works with 5.5.2 ), or by setting
charon.plugins.kernel-netlink.fwmark 
 to an arbitrary number not used 
yet
as firewall mark (this works since 5.3.3 ).  However, I'm not sure if
that will return different values in RTA_GATEWAY/RTA_OIF or if it would
still be necessary to parse RTA_MULTIPATH.  How exactly do these kind of
kind of multipath routes compare to multiple routes with different
priorities/metrics?  In your case you have multiple paths with the same
weight, how is the actual nexthop/interface chosen by the kernel?
Round-robin?  Random?

Regards,
Tobias



___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users


___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Dusan Ilic]

I have found the issue! Not a Strongswan one after all :)

This is my ip rules output:

# ip rule
0:  from all lookup local
100:from 85.24.x.x lookup WAN1
101:from 90.225.x.x lookup WAN2
102:from 10.248.x.x lookup WAN3
104:from 46.195.x.x lookup WAN4
121:from all fwmark 0x100/0xf00 lookup WAN1
122:from all fwmark 0x200/0xf00 lookup WAN2
123:from all fwmark 0x300/0xf00 lookup WAN3
124:from all fwmark 0x400/0xf00 lookup WAN4
220:from all lookup main
32766:  from all lookup main
32767:  from all lookup default

When deleting rule 121 my VPN clients starts respecting the multipath 
routes on the gateway and get routed out on ppp0 (WAN3) as wanted. 
However, then my specific policy rules (marked with 0x100) stops going 
out on vlan847 (WAN1) of course, which is not wanted. Do you have any 
suggestion how I could make both work? I'm just guessing here, but 
probably all incoming traffic on each of the WAN interfaces gets marked 
with the above marks, so that return traffic goes out the same interface 
which if the right behaviour, however not in my VPN remote access case!



Den 2017-04-26 kl. 23:19, skrev Noel Kuntze:

Hello Dusan,

In general, charon does not route any packets of the kernel. Charon is out of 
the loop there,
however, it installs routes into routing table 220 by default to make sure the 
packets
that are going to be protected with IPsec reach the remote subnet.
This means that when charon picks the wrong route, the traffic that is 
forwarded or
sent by the kernel to the remote subnet is going to be routed over the last 
fitting route that
the kernel-netlink plugin finds, as Tobias wrote.

In order to prevent this from happening, you have to disable the installation 
of routes.
You do this by setting "charon.install_routes" to "no" in strongswan.conf or try
to set charon.plugins.kernel-netlink.fwmark to a mark value you don't use.

Kind regards,
Noel

On 26.04.2017 22:23, Dusan Ilic wrote:

Hi  again Tobias,

After reading your post once more I suspect we are talking about different 
things. I see you qouted my question why the last multipath is being chosen by 
Strongswan when configuring left=%any and initiating the connection, however Im 
talking about the route Strongswan chooses to forward remote clients out on the 
Internet. Do you think the problem is the same? My remote clients are 
connecting to Public IP on vlsn847, and when accessing the internet 
(leftsubnet=0.0.0.0/0) they are being always routed out the same interface, 
that is vlsn847. What I expect is that Strongswan will hand over the vpn 
clients traffic to the Linux kernel, which will do a normal route lookup and 
route the clients out on interface ppp0. Isnt this possible? Is it maybe 
something in Strongswan that makes it forward incoming traffic out on the 
Internet through the same interface?

 Tobias Brunner skrev 

Hi Dusan,


default
  nexthop via 90.225 .x.x  dev vlan845 weight 1
  nexthop via 10.248 .x.x  dev ppp0 weight 256
  nexthop via 85.24 .x.x  dev vlan847 weight 1
  nexthop via 46.195 .x.x  dev ppp1 weight 1

My gateway is configured to use 10.248.0 .x as "default route" 
(highest
weight/priority), but when Strongswan tried to initiate the tunnel it
seems to always default too the last route, 46.195 .x.x, and this 
wont
work as the remote peer is expecting 85.24 .x.x.

These kinds of multipath routes (via RTA_MULTIPATH) are currently not
supported by strongSwan when looking up source addresses/nexthops.  The
kernel-netlink plugin only sees one of these via RTA_GATEWAY and
RTA_OIF.  You could try to switch to the kernel's default route lookup
by setting either charon.install_routes=no (disables route installation
by strongSwan altogether, only works with 5.5.2 ), or by setting
charon.plugins.kernel-netlink.fwmark 
 to an arbitrary number not used 
yet
as firewall mark (this works since 5.3.3 ).  However, I'm not sure if
that will return different values in RTA_GATEWAY/RTA_OIF or if it would
still be necessary to parse RTA_MULTIPATH.  How exactly do these kind of
kind of multipath routes compare to multiple routes with different
priorities/metrics?  In your case you have multiple paths with the same
weight, how is the actual nexthop/interface chosen by the kernel?
Round-robin?  Random?

Regards,
Tobias



___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users


___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Noel Kuntze]

Hello Dusan,

In general, charon does not route any packets of the kernel. Charon is out of 
the loop there,
however, it installs routes into routing table 220 by default to make sure the 
packets
that are going to be protected with IPsec reach the remote subnet.
This means that when charon picks the wrong route, the traffic that is 
forwarded or
sent by the kernel to the remote subnet is going to be routed over the last 
fitting route that
the kernel-netlink plugin finds, as Tobias wrote.

In order to prevent this from happening, you have to disable the installation 
of routes.
You do this by setting "charon.install_routes" to "no" in strongswan.conf or try
to set charon.plugins.kernel-netlink.fwmark to a mark value you don't use.

Kind regards,
Noel

On 26.04.2017 22:23, Dusan Ilic wrote:
> Hi  again Tobias,
>
> After reading your post once more I suspect we are talking about different 
> things. I see you qouted my question why the last multipath is being chosen 
> by Strongswan when configuring left=%any and initiating the connection, 
> however Im talking about the route Strongswan chooses to forward remote 
> clients out on the Internet. Do you think the problem is the same? My remote 
> clients are connecting to Public IP on vlsn847, and when accessing the 
> internet (leftsubnet=0.0.0.0/0) they are being always routed out the same 
> interface, that is vlsn847. What I expect is that Strongswan will hand over 
> the vpn clients traffic to the Linux kernel, which will do a normal route 
> lookup and route the clients out on interface ppp0. Isnt this possible? Is it 
> maybe something in Strongswan that makes it forward incoming traffic out on 
> the Internet through the same interface?
>
>  Tobias Brunner skrev 
>
> Hi Dusan,
>
> > default
> >  nexthop via 90.225 .x.x  dev vlan845 weight 1
> >  nexthop via 10.248 .x.x  dev ppp0 weight 256
> >  nexthop via 85.24 .x.x  dev vlan847 weight 1
> >  nexthop via 46.195 .x.x  dev ppp1 weight 1
> >
> > My gateway is configured to use 10.248.0 .x as "default 
> > route" (highest
> > weight/priority), but when Strongswan tried to initiate the tunnel it
> > seems to always default too the last route, 46.195 .x.x, and 
> > this wont
> > work as the remote peer is expecting 85.24 .x.x.
>
> These kinds of multipath routes (via RTA_MULTIPATH) are currently not
> supported by strongSwan when looking up source addresses/nexthops.  The
> kernel-netlink plugin only sees one of these via RTA_GATEWAY and
> RTA_OIF.  You could try to switch to the kernel's default route lookup
> by setting either charon.install_routes=no (disables route installation
> by strongSwan altogether, only works with 5.5.2 ), or by setting
> charon.plugins.kernel-netlink.fwmark 
>  to an arbitrary number not used 
> yet
> as firewall mark (this works since 5.3.3 ).  However, I'm not sure 
> if
> that will return different values in RTA_GATEWAY/RTA_OIF or if it would
> still be necessary to parse RTA_MULTIPATH.  How exactly do these kind of
> kind of multipath routes compare to multiple routes with different
> priorities/metrics?  In your case you have multiple paths with the same
> weight, how is the actual nexthop/interface chosen by the kernel?
> Round-robin?  Random?
>
> Regards,
> Tobias
>
>
>
> ___
> Users mailing list
> Users@lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users

-- 
Noel Kuntze
IT security consultant

GPG Key ID: 0x0739AD6C
Fingerprint: 3524 93BE B5F7 8E63 1372 AF2D F54E E40B 0739 AD6C






signature.asc
Description: OpenPGP digital signature
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Dusan Ilic]

Hi  again Tobias,

After reading your post once more I suspect we are talking about different 
things. I see you qouted my question why the last multipath is being chosen by 
Strongswan when configuring left=%any and initiating the connection, however Im 
talking about the route Strongswan chooses to forward remote clients out on the 
Internet. Do you think the problem is the same? My remote clients are 
connecting to Public IP on vlsn847, and when accessing the internet 
(leftsubnet=0.0.0.0/0) they are being always routed out the same interface, 
that is vlsn847. What I expect is that Strongswan will hand over the vpn 
clients traffic to the Linux kernel, which will do a normal route lookup and 
route the clients out on interface ppp0. Isnt this possible? Is it maybe 
something in Strongswan that makes it forward incoming traffic out on the 
Internet through the same interface?

 Tobias Brunner skrev 

>Hi Dusan,
>
>> default
>>  nexthop via 90.225.x.x  dev vlan845 weight 1
>>  nexthop via 10.248.x.x  dev ppp0 weight 256
>>  nexthop via 85.24.x.x  dev vlan847 weight 1
>>  nexthop via 46.195.x.x  dev ppp1 weight 1
>>
>> My gateway is configured to use 10.248.0.x as "default route" (highest 
>> weight/priority), but when Strongswan tried to initiate the tunnel it 
>> seems to always default too the last route, 46.195.x.x, and this wont 
>> work as the remote peer is expecting 85.24.x.x.
>
>These kinds of multipath routes (via RTA_MULTIPATH) are currently not
>supported by strongSwan when looking up source addresses/nexthops.  The
>kernel-netlink plugin only sees one of these via RTA_GATEWAY and
>RTA_OIF.  You could try to switch to the kernel's default route lookup
>by setting either charon.install_routes=no (disables route installation
>by strongSwan altogether, only works with 5.5.2), or by setting
>charon.plugins.kernel-netlink.fwmark to an arbitrary number not used yet
>as firewall mark (this works since 5.3.3).  However, I'm not sure if
>that will return different values in RTA_GATEWAY/RTA_OIF or if it would
>still be necessary to parse RTA_MULTIPATH.  How exactly do these kind of
>kind of multipath routes compare to multiple routes with different
>priorities/metrics?  In your case you have multiple paths with the same
>weight, how is the actual nexthop/interface chosen by the kernel?
>Round-robin?  Random?
>
>Regards,
>Tobias
>
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Dusan Ilic]

I need load distribution and policy routing  just dont cut it,its to static.
All Ipsec connections are configured in ipsec.conf to use vlsn847 interface for 
incoming connections (left) which means Strongswan always use that route as 
initiatiator and responder, only problem is that Strongswan also default to 
this interface for forwarding vpn clients out the Internet,  even though the 
multipath route in Linux says otherwise.

So the issue seem to lay within Strongswan defaulting to the same interface as 
incoming connections for forwarding traffic. I will try the workarounds 
suggested earlier and see if that does any difference. Thank you.

 Martin Willi skrev 

>Hi,
>
>> How exactly do these kind of kind of multipath routes compare to
>> multiple routes with different priorities/metrics?  In your case you
>> have multiple paths with the same weight, how is the actual
>> nexthop/interface chosen by the kernel?
>
>The nexthop of a multipath route is selected randomly considering its
>weight, based on a hash of the packet address to keep flows on the same
>path. With multiple routes with a priority, only the route with the
>lowest priority is used.
>
>When used with IPsec, these multipath routes get somewhat
>unpredictable; the route lookup for the unencrypted traffic yields a
>route, but the IPsec policy used may be configured to use the outer
>tunnel source address of a different interface, depending on where the
>tunnel was established over.
>
>In short, multipath routes won't work very well with strongSwan as-is.
>If you don't need load sharing, use multiple distinct routes with
>different priorities. If you want to share load, you may consider using
>policy based routing, for example using marks. But be warned, this then
>gets close to rocket science.
>
>Regards
>Martin
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Martin Willi]

Hi,

> How exactly do these kind of kind of multipath routes compare to
> multiple routes with different priorities/metrics?  In your case you
> have multiple paths with the same weight, how is the actual
> nexthop/interface chosen by the kernel?

The nexthop of a multipath route is selected randomly considering its
weight, based on a hash of the packet address to keep flows on the same
path. With multiple routes with a priority, only the route with the
lowest priority is used.

When used with IPsec, these multipath routes get somewhat
unpredictable; the route lookup for the unencrypted traffic yields a
route, but the IPsec policy used may be configured to use the outer
tunnel source address of a different interface, depending on where the
tunnel was established over.

In short, multipath routes won't work very well with strongSwan as-is.
If you don't need load sharing, use multiple distinct routes with
different priorities. If you want to share load, you may consider using
policy based routing, for example using marks. But be warned, this then
gets close to rocket science.

Regards
Martin
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Tobias Brunner]

Hi Dusan,

> default
>  nexthop via 90.225.x.x  dev vlan845 weight 1
>  nexthop via 10.248.x.x  dev ppp0 weight 256
>  nexthop via 85.24.x.x  dev vlan847 weight 1
>  nexthop via 46.195.x.x  dev ppp1 weight 1
>
> My gateway is configured to use 10.248.0.x as "default route" (highest 
> weight/priority), but when Strongswan tried to initiate the tunnel it 
> seems to always default too the last route, 46.195.x.x, and this wont 
> work as the remote peer is expecting 85.24.x.x.

These kinds of multipath routes (via RTA_MULTIPATH) are currently not
supported by strongSwan when looking up source addresses/nexthops.  The
kernel-netlink plugin only sees one of these via RTA_GATEWAY and
RTA_OIF.  You could try to switch to the kernel's default route lookup
by setting either charon.install_routes=no (disables route installation
by strongSwan altogether, only works with 5.5.2), or by setting
charon.plugins.kernel-netlink.fwmark to an arbitrary number not used yet
as firewall mark (this works since 5.3.3).  However, I'm not sure if
that will return different values in RTA_GATEWAY/RTA_OIF or if it would
still be necessary to parse RTA_MULTIPATH.  How exactly do these kind of
kind of multipath routes compare to multiple routes with different
priorities/metrics?  In your case you have multiple paths with the same
weight, how is the actual nexthop/interface chosen by the kernel?
Round-robin?  Random?

Regards,
Tobias

___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Dusan Ilic]

No one?


Den 2017-04-21 kl. 10:16, skrev Dusan Ilic:

Hi!

I have some issues, please read on.

1. I have one side of the IP-sec tunnel with dynamic IP (associated 
with a dynamic hostname), I would like not need to change the 
"left"-parameter in both ipsec.conf and ipsec.secrets whenever the 
local WAN IP changes, so I have tried putting "left = %any" or "left = 
%hostname". Now, with %hostname (preferable) it wont connect, but with 
%any it does connect, sometimes. I can see in the documentation that 
%any does a local root lookup if the local host is initiating the 
connection, but only accepting all local IP-adresses if it responds to 
the remote peer initiation. In my case ths always work when the remote 
peer is initiating the connection, but if my local end initiates it 
(ie start=route) it seem to choose the wrong public source IP to 
connect from.
In my case, my local gateway running Strongswan have multiple public 
interfaces (but only one should be used for IP-sec tunnels), se below 
route information:


default
nexthop via 90.225.x.x  dev vlan845 weight 1
nexthop via 10.248.x.x  dev ppp0 weight 256
nexthop via 85.24.x.x  dev vlan847 weight 1
nexthop via 46.195.x.x  dev ppp1 weight 1

My gateway is configured to use 10.248.0.x as "default route" (highest 
weight/priority), but when Strongswan tried to initiate the tunnel it 
seems to always default too the last route, 46.195.x.x, and this wont 
work as the remote peer is expecting 85.24.x.x. Now, is there a way to 
tell Strongswan to use this IP/interface? I hope "left=%hostname" 
would work, because the hostname is dynamically ponting to the IP at 
interface vlan847, but as already stated this isn't working either.


Any suggestions?

2. Probably also cause by the above routing setup (wild guess), I also 
have IKEv2 EAP roadwarrior connectin in Strongswan on the same 
interface. The Strongswan client on Android connects to my public 
hostname, and everything works (and in this setup I can have 
left=%hostname on the server), it's a full tunnel with 
leftsubnet=0.0.0.0/0. However, all VPN-clients are beeing routed out 
on this same interface the connect to, so the third route above is 
being automatically used (vlan847) instead of the second route on ppp0 
(with higher weight/priority). Locally connected clients to the 
gateway all gets routed out on ppp0, but not VPN-clients. Why is this, 
and what can be done to correct this? The reason for me wanting the 
VPN clients connecting on vlan847 also routed on the the Internet on 
ppp0 is simple, ppp0 is a VPN connection from the gateway out to the 
Internet.


I can add that in strongswan.conf I have changed so that all 
VPN-routes added by Strongswan is done in the standard, main routing 
table (instead of 220), so technically the VPN-clients should be 
routed the same as the local clients by the gateway.


___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Tunnels with dynamic IP and another route issue

[Dusan Ilic]

Okey, one correction

left=%hostname is working for one of my tunnels, but not the other. See 
below.


The working:
sending cert request for "C=US, O=Let's Encrypt, CN=Let's Encrypt 
Authority X3"

authentication of 'hostname' (myself) with pre-shared key
establishing CHILD_SA Azure
generating IKE_AUTH request 1 [ IDi CERTREQ IDr AUTH SA TSi TSr 
N(EAP_ONLY) ]

sending packet: from 85.24.x.x[500] to 137.135.x.x[500] (380 bytes)
received packet: from 137.135.x.x[500] to 85.24.x.x[500] (204 bytes)
parsed IKE_AUTH response 1 [ IDr AUTH SA TSi TSr ]
authentication of '137.135.x.x' with pre-shared key successful
IKE_SA Azure[2] established between 
85.24.x.x[hostname]...137.135.x.x[137.135.x.x]

scheduling reauthentication in 27923s
maximum IKE_SA lifetime 28463s
connection 'Azure' established successfully

The non-working:
sending cert request for "C=US, O=Let's Encrypt, CN=Let's Encrypt 
Authority X3"

authentication of 'hostname' (myself) with pre-shared key
establishing CHILD_SA Wesafe
generating IKE_AUTH request 1 [ IDi CERTREQ IDr AUTH SA TSi TSr 
N(MULT_AUTH) N(EAP_ONLY) ]

sending packet: from 85.24.x.x[500] to 94.254.x.x[500] (380 bytes)
received packet: from 94.254.x.x[500] to 85.24.x.x[500] (76 bytes)
parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]
received AUTHENTICATION_FAILED notify error
establishing connection 'Wesafe' failed

ipsec.secrets
%hostname 137.135.x.x : PSK ""
%hostname 94.254.x.x : PSK "x"

I don't know why Strongswan seems to send my local certificate, it 
should only be used when roadwarriors connect.


Den 2017-04-21 kl. 10:16, skrev Dusan Ilic:

Hi!

I have some issues, please read on.

1. I have one side of the IP-sec tunnel with dynamic IP (associated 
with a dynamic hostname), I would like not need to change the 
"left"-parameter in both ipsec.conf and ipsec.secrets whenever the 
local WAN IP changes, so I have tried putting "left = %any" or "left = 
%hostname". Now, with %hostname (preferable) it wont connect, but with 
%any it does connect, sometimes. I can see in the documentation that 
%any does a local root lookup if the local host is initiating the 
connection, but only accepting all local IP-adresses if it responds to 
the remote peer initiation. In my case ths always work when the remote 
peer is initiating the connection, but if my local end initiates it 
(ie start=route) it seem to choose the wrong public source IP to 
connect from.
In my case, my local gateway running Strongswan have multiple public 
interfaces (but only one should be used for IP-sec tunnels), se below 
route information:


default
nexthop via 90.225.x.x  dev vlan845 weight 1
nexthop via 10.248.x.x  dev ppp0 weight 256
nexthop via 85.24.x.x  dev vlan847 weight 1
nexthop via 46.195.x.x  dev ppp1 weight 1

My gateway is configured to use 10.248.0.x as "default route" (highest 
weight/priority), but when Strongswan tried to initiate the tunnel it 
seems to always default too the last route, 46.195.x.x, and this wont 
work as the remote peer is expecting 85.24.x.x. Now, is there a way to 
tell Strongswan to use this IP/interface? I hope "left=%hostname" 
would work, because the hostname is dynamically ponting to the IP at 
interface vlan847, but as already stated this isn't working either.


Any suggestions?

2. Probably also cause by the above routing setup (wild guess), I also 
have IKEv2 EAP roadwarrior connectin in Strongswan on the same 
interface. The Strongswan client on Android connects to my public 
hostname, and everything works (and in this setup I can have 
left=%hostname on the server), it's a full tunnel with 
leftsubnet=0.0.0.0/0. However, all VPN-clients are beeing routed out 
on this same interface the connect to, so the third route above is 
being automatically used (vlan847) instead of the second route on ppp0 
(with higher weight/priority). Locally connected clients to the 
gateway all gets routed out on ppp0, but not VPN-clients. Why is this, 
and what can be done to correct this? The reason for me wanting the 
VPN clients connecting on vlan847 also routed on the the Internet on 
ppp0 is simple, ppp0 is a VPN connection from the gateway out to the 
Internet.


I can add that in strongswan.conf I have changed so that all 
VPN-routes added by Strongswan is done in the standard, main routing 
table (instead of 220), so technically the VPN-clients should be 
routed the same as the local clients by the gateway.

___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users


___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] Tunnels with dynamic IP and another route issue

[Dusan Ilic]

Hi!

I have some issues, please read on.

1. I have one side of the IP-sec tunnel with dynamic IP (associated with 
a dynamic hostname), I would like not need to change the 
"left"-parameter in both ipsec.conf and ipsec.secrets whenever the local 
WAN IP changes, so I have tried putting "left = %any" or "left = 
%hostname". Now, with %hostname (preferable) it wont connect, but with 
%any it does connect, sometimes. I can see in the documentation that 
%any does a local root lookup if the local host is initiating the 
connection, but only accepting all local IP-adresses if it responds to 
the remote peer initiation. In my case ths always work when the remote 
peer is initiating the connection, but if my local end initiates it (ie 
start=route) it seem to choose the wrong public source IP to connect from.
In my case, my local gateway running Strongswan have multiple public 
interfaces (but only one should be used for IP-sec tunnels), se below 
route information:


default
nexthop via 90.225.x.x  dev vlan845 weight 1
nexthop via 10.248.x.x  dev ppp0 weight 256
nexthop via 85.24.x.x  dev vlan847 weight 1
nexthop via 46.195.x.x  dev ppp1 weight 1

My gateway is configured to use 10.248.0.x as "default route" (highest 
weight/priority), but when Strongswan tried to initiate the tunnel it 
seems to always default too the last route, 46.195.x.x, and this wont 
work as the remote peer is expecting 85.24.x.x. Now, is there a way to 
tell Strongswan to use this IP/interface? I hope "left=%hostname" would 
work, because the hostname is dynamically ponting to the IP at interface 
vlan847, but as already stated this isn't working either.


Any suggestions?

2. Probably also cause by the above routing setup (wild guess), I also 
have IKEv2 EAP roadwarrior connectin in Strongswan on the same 
interface. The Strongswan client on Android connects to my public 
hostname, and everything works (and in this setup I can have 
left=%hostname on the server), it's a full tunnel with 
leftsubnet=0.0.0.0/0. However, all VPN-clients are beeing routed out on 
this same interface the connect to, so the third route above is being 
automatically used (vlan847) instead of the second route on ppp0 (with 
higher weight/priority). Locally connected clients to the gateway all 
gets routed out on ppp0, but not VPN-clients. Why is this, and what can 
be done to correct this? The reason for me wanting the VPN clients 
connecting on vlan847 also routed on the the Internet on ppp0 is simple, 
ppp0 is a VPN connection from the gateway out to the Internet.


I can add that in strongswan.conf I have changed so that all VPN-routes 
added by Strongswan is done in the standard, main routing table (instead 
of 220), so technically the VPN-clients should be routed the same as the 
local clients by the gateway.

___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users