Re: [strongSwan] Not Able to Connect
Hi,
if you want static virtual IPs then you can use one of the following two
mechanism:
https://www.strongswan.org/testing/testresults/ikev2/dhcp-static-client-id/
or
https://www.strongswan.org/testing/testresults/ikev2/dhcp-static-mac/
Just have a look at the console log how the DHCP server has to
be configured.
Regards
Andreas
On 29.03.2018 20:12, Info wrote:
>
> On 03/29/2018 10:21 AM, Andreas Steffen wrote:
>> Hi,
>>
>> yes you can fully integrate a remote host into a LAN by using the
>> farp and dhcp plugins on the VPN gateway so that the gateway
>> acts as an ARP proxy for the remote clients. Have a look at the
>> following example scenario based on swanctl:
>>
>> https://www.strongswan.org/testing/testresults/swanctl/dhcp-dynamic/
>>
>> In swanctl.conf
>>
>>
>> https://www.strongswan.org/testing/testresults/swanctl/dhcp-dynamic/moon.swanctl.conf
>>
>> use pools = dhcp and in strongswan.conf
>>
>>
>> https://www.strongswan.org/testing/testresults/swanctl/dhcp-dynamic/moon.strongswan.conf
>>
>> define the DCHP server to be used.
>>
>> Regards
>>
>> Andreas
> Thanks Andreas. You likely know (but for the benefit of others), things
> are done differently in RHEL. For the plugins normally loaded by
> /etc/strongswan/strongswan.conf, in the case of RHEL there's just a call to:
> charon {
> load_modular = yes
> plugins {
> include strongswan.d/charon/*.conf
> }
> }
>
> ... and in that directory there's a .conf for each plugin. Given the
> charon.log, all required plugins are already being loaded without my
> intervention (at least for charon, Idk about swanctl), including farp
> and dhcp. Since I no longer use the stroke plugin I set in its .conf
> file load = no. And in dhcp.conf I set server = 192.168.1.10 which
> will be the LAN DHCP server.
>
> Thing is since I run servers I've always used static IPs, so I'll have
> to figure out DHCP predictable assignment. But with the transition to
> IPV6 I will be using DHCP exclusively. (for the love of all that's holy)
>
>
>
>
>
--
==
Andreas Steffen andreas.stef...@strongswan.org
strongSwan - the Open Source VPN Solution! www.strongswan.org
Institute for Networked Solutions
HSR University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===[INS-HSR]==
Re: [strongSwan] Not Able to Connect
On 03/29/2018 10:21 AM, Andreas Steffen wrote:
> Hi,
>
> yes you can fully integrate a remote host into a LAN by using the
> farp and dhcp plugins on the VPN gateway so that the gateway
> acts as an ARP proxy for the remote clients. Have a look at the
> following example scenario based on swanctl:
>
> https://www.strongswan.org/testing/testresults/swanctl/dhcp-dynamic/
>
> In swanctl.conf
>
>
> https://www.strongswan.org/testing/testresults/swanctl/dhcp-dynamic/moon.swanctl.conf
>
> use pools = dhcp and in strongswan.conf
>
>
> https://www.strongswan.org/testing/testresults/swanctl/dhcp-dynamic/moon.strongswan.conf
>
> define the DCHP server to be used.
>
> Regards
>
> Andreas
Thanks Andreas. You likely know (but for the benefit of others), things
are done differently in RHEL. For the plugins normally loaded by
/etc/strongswan/strongswan.conf, in the case of RHEL there's just a call to:
charon {
load_modular = yes
plugins {
include strongswan.d/charon/*.conf
}
}
... and in that directory there's a .conf for each plugin. Given the
charon.log, all required plugins are already being loaded without my
intervention (at least for charon, Idk about swanctl), including farp
and dhcp. Since I no longer use the stroke plugin I set in its .conf
file load = no. And in dhcp.conf I set server = 192.168.1.10 which
will be the LAN DHCP server.
Thing is since I run servers I've always used static IPs, so I'll have
to figure out DHCP predictable assignment. But with the transition to
IPV6 I will be using DHCP exclusively. (for the love of all that's holy)
Re: [strongSwan] Not Able to Connect
Hi, yes you can fully integrate a remote host into a LAN by using the farp and dhcp plugins on the VPN gateway so that the gateway acts as an ARP proxy for the remote clients. Have a look at the following example scenario based on swanctl: https://www.strongswan.org/testing/testresults/swanctl/dhcp-dynamic/ In swanctl.conf https://www.strongswan.org/testing/testresults/swanctl/dhcp-dynamic/moon.swanctl.conf use pools = dhcp and in strongswan.conf https://www.strongswan.org/testing/testresults/swanctl/dhcp-dynamic/moon.strongswan.conf define the DCHP server to be used. Regards Andreas On 29.03.2018 18:57, Info wrote: > True. Although I infer that 'pools' might be address pools (as with > DHCP), I can find no evidence of this. And I now notice the 'pools' > definition further down. > > But I'd like this VPN to be 'transparent'. IOW I'd like my remote > machines and LAN members to use the same IP as they do in the LAN. If > possible I'd like to avoid virtual IPs. Is there any way to do this? > > And I gather that in the IPSec gateway for the LAN, I can define > different definitions for different remote machines, but I can't work > out how this would be structured with swanctl. I'd actually prefer to > keep the same definition for all remote initiators, but things may not > always work out like we want. > > Side question: I'm also in the process of transitioning the LAN to > IPV6. As my ISP will not foreseeably have IPV6 (Frontier Comm) I'll > need to use a tunnel broker. Will this be a problem with Strongswan, > and can the Android app do IPV6? > > > On 03/28/2018 02:35 PM, Andreas Steffen wrote: >> The connection setup gets now very far but finally fails because >> the pools defined by >> >> pools = primary-pool-ipv4, primary-pool-ipv6 >> >> don't seem be defined (have you added a pools section in swanctl.conf?) >> and therefore no virtual IP can be allocated to the initiator >> >> Wed, 2018-03-28 08:31 15[IKE] >> peer requested virtual IP %any >> no virtual IP found for %any requested by 'C=US, O=Quantum >> CN=aries.darkmatter.org' >> peer requested virtual IP %any6 >> no virtual IP found for %any6 requested by 'C=US, O=Quantum >> CN=aries.darkmatter.org' >> no virtual IP found, sending INTERNAL_ADDRESS_FAILURE >> >> Regards >> >> Andreas >> >> On 28.03.2018 17:37, Info wrote: >>> I have no way of interpreting the syntax of these proposals as there's >>> no definitive description. Maybe '-' separates different options in a >>> category and ',' separates categories? But it also doesn't explain >>> "classic and combined-mode algos" nor not to mix them. I can't know >>> these things by instinct. >>> >>> Something else is wrong with the example. I copied it -exactly- (except >>> I used your esp_proposals), and the error log is attached. >>> >>> >>> >>> On 03/28/2018 02:21 AM, Andreas Steffen wrote: Hi, as your log explicitly says: > Tue, 2018-03-27 15:13 15[CFG] classic and combined-mode (AEAD) > encryption algorithms can't be contained in the same IKE proposal Thus instead of esp_proposals = > aes192gcm16-aes128gcm16-aes192-ecp256,aes192-sha256-modp3072,default you must define esp_proposals = aes192gcm16-aes128gcm16-ecp256,aes192-sha256-ecp256-modp3072,default Regards Andreas > -- == Andreas Steffen andreas.stef...@strongswan.org strongSwan - the Open Source VPN Solution! www.strongswan.org Institute for Networked Solutions HSR University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===[INS-HSR]==
Re: [strongSwan] IPsec broken for iphone with ios11?
I am using IPsec w/ IKEv2 reliably on iOS 11.2.6 On Thu, Mar 29, 2018 at 12:23 PM, Harald Dunkel wrote: > Hi folks, > > is it just me, or is IPsec broken for ios 11 (iphone)? I can establish > an IPsec connection once, but if I reconnect then the routing appears > to be broken. I cannot ping the DNServer on the remote net. > > My ipad (ios 10) with a similar profile has no such problem. > > Can anybody reproduce this? > > > Regards > Harri > -- Rob Leonard RJL Contracting Cell: (248) 214 7559 E-Mail: rjlcontract...@gmail.com
Re: [strongSwan] Not Able to Connect
True. Although I infer that 'pools' might be address pools (as with DHCP), I can find no evidence of this. And I now notice the 'pools' definition further down. But I'd like this VPN to be 'transparent'. IOW I'd like my remote machines and LAN members to use the same IP as they do in the LAN. If possible I'd like to avoid virtual IPs. Is there any way to do this? And I gather that in the IPSec gateway for the LAN, I can define different definitions for different remote machines, but I can't work out how this would be structured with swanctl. I'd actually prefer to keep the same definition for all remote initiators, but things may not always work out like we want. Side question: I'm also in the process of transitioning the LAN to IPV6. As my ISP will not foreseeably have IPV6 (Frontier Comm) I'll need to use a tunnel broker. Will this be a problem with Strongswan, and can the Android app do IPV6? On 03/28/2018 02:35 PM, Andreas Steffen wrote: > The connection setup gets now very far but finally fails because > the pools defined by > > pools = primary-pool-ipv4, primary-pool-ipv6 > > don't seem be defined (have you added a pools section in swanctl.conf?) > and therefore no virtual IP can be allocated to the initiator > > Wed, 2018-03-28 08:31 15[IKE] > peer requested virtual IP %any > no virtual IP found for %any requested by 'C=US, O=Quantum > CN=aries.darkmatter.org' > peer requested virtual IP %any6 > no virtual IP found for %any6 requested by 'C=US, O=Quantum > CN=aries.darkmatter.org' > no virtual IP found, sending INTERNAL_ADDRESS_FAILURE > > Regards > > Andreas > > On 28.03.2018 17:37, Info wrote: >> I have no way of interpreting the syntax of these proposals as there's >> no definitive description. Maybe '-' separates different options in a >> category and ',' separates categories? But it also doesn't explain >> "classic and combined-mode algos" nor not to mix them. I can't know >> these things by instinct. >> >> Something else is wrong with the example. I copied it -exactly- (except >> I used your esp_proposals), and the error log is attached. >> >> >> >> On 03/28/2018 02:21 AM, Andreas Steffen wrote: >>> Hi, >>> >>> as your log explicitly says: >>> Tue, 2018-03-27 15:13 15[CFG] classic and combined-mode (AEAD) encryption algorithms can't be contained in the same IKE proposal >>> Thus instead of >>> >>> esp_proposals = aes192gcm16-aes128gcm16-aes192-ecp256,aes192-sha256-modp3072,default >>> you must define >>> >>> esp_proposals = >>> aes192gcm16-aes128gcm16-ecp256,aes192-sha256-ecp256-modp3072,default >>> >>> Regards >>> >>> Andreas >>>
[strongSwan] IPsec broken for iphone with ios11?
Hi folks, is it just me, or is IPsec broken for ios 11 (iphone)? I can establish an IPsec connection once, but if I reconnect then the routing appears to be broken. I cannot ping the DNServer on the remote net. My ipad (ios 10) with a similar profile has no such problem. Can anybody reproduce this? Regards Harri
Re: [strongSwan] Clarifying behaviour around NAT-T and remapping
> On Mar 29, 2018, at 5:46 AM, Tobias Brunner wrote: > > Hi Rich, > >> Mar 27 15:47:35 stg-vault-zk04 charon: 14[NET] >> sending packet: from 172.17.128.86[500] to 13.88.23.150[500] (160 bytes) >> Mar 27 15:47:35 stg-vault-zk04 charon: 07[NET] >> received packet: from 13.88.23.150[1031] to 172.17.128.86[500] (140 bytes) > > Yeah, that's the problem. Why is a packet first accepted on port 500 > and then returned from port 1031? You wrote Azure has a "less-static > NAT service". But how does that makes sense? You configure the NAT to > forward port 500 to your VPN gateway and then it maps the response from > that port to a new external port instead of using the existing static > NAT mapping? That’s exactly what’s happening, yes. There’s two different “nat settings" — one to _always_ forward 500/4500 through to the host for incoming packets (static “port forwarding” NAT) and a separate connection-tracking kind of NAT which handles the outgoing connections (and which _usually_ maps 500->500 and 4500->4500 except that sometimes it remaps.) Azure has, thankfully, abandoned this model in its newer offerings but alas, those aren’t the ones we’re using. (Not a VPN gateway, though, all transport mode, full mesh.) > Since the remote port is now not 500 anymore strongSwan won't switch to > remote port 4500: > we wouldn't have been able to send a message to it as we only > add a non-ESP marker if neither port is 500 Aha, those two things were my working theory so it’s good to have them confirmed. >> Mar 27 15:47:35 stg-vault-zk06 charon: 10[NET] <80> sending packet: from >> 10.0.0.59[500] to 54.186.244.242[500] (524 bytes) >> Mar 27 15:47:35 stg-vault-zk06 charon: 03[NET] sending packet: from >> 10.0.0.59[500] to 54.186.244.242[4500] (36 bytes) >> >> ^ I don't know why this packet went from 500 to 4500 > > Because it received it on that port. But it's strange that this even > works. The initiator uses port 4500 and sends to port 1031, so it > should add a non-ESP marker. However, as responder the non-ESP marker > is currently only stripped from the packet if neither port is 500. Here > the responder's local port is 500, so the marker is not removed and > parsing the IKE header should fail. Did you patch that? If not, what > version are you using? I haven’t patched anything. We’re using 5.6.1 from Ubuntu unstable (backported to Trusty/Xenial). I don’t see any relevant patches in the Ubuntu package, but on the other hand, parsing the IKE header _does_ fail, so I think we’re getting expected behaviour. > I pushed a patch to the port-float branch that might help. And as a > workaround you could just initiate the connection directly to port 4500 > (remote_port=4500), and from port 4500 (local_port=4500). See [1]. I’ll give both of those a shot and report back. (It’s not clear to me from the NatTraversal page if this will work with IKEv1 but I’ll find out soon enough.) Thanks! -Rich
Re: [strongSwan] vpn connection brings down local connections
On 2018-03-26 3:46 PM, Noel Kuntze wrote: On 26.03.2018 19:42, Chris Purves wrote: I have a windows client that I want to connect to the gateway and only the gateway. The gateway is behind a router (so is the client, for that matter). I can connect to the gateway, but once the vpn connection is made, the gateway is no longer available on the local network. ipsec.conf: config setup charondebug="ike 1, knl 1, cfg 0" uniqueids = no conn ikev2-vpn auto=add keyexchange=ikev2 forceencaps=yes dpdaction=clear dpddelay=300s rekey=no left=192.168.200.105 leftsubnet=0.0.0.0/0 leftid=@vesuvius.picomole.com leftcert=/etc/ipsec.d/certs/vpn-server-cert.pem leftsendcert=always right=%any rightid=%any rightauth=eap-mschapv2 rightsourceip=192.168.200.200/28 rightsubnet=0.0.0.0/0 rightsendcert=never eap_identity=%identity > Remove the rightsubnet setting, it's wrong. > Thanks, Noel! Your terse response has solved my problem. -- Chris Purves "...he was right in front of me trying to block my way, so I took him out." - Jean Chrétien
Re: [strongSwan] Clarifying behaviour around NAT-T and remapping
Hi Rich, > Mar 27 15:47:35 stg-vault-zk04 charon: 14[NET] sending > packet: from 172.17.128.86[500] to 13.88.23.150[500] (160 bytes) > Mar 27 15:47:35 stg-vault-zk04 charon: 07[NET] > received packet: from 13.88.23.150[1031] to 172.17.128.86[500] (140 bytes) Yeah, that's the problem. Why is a packet first accepted on port 500 and then returned from port 1031? You wrote Azure has a "less-static NAT service". But how does that makes sense? You configure the NAT to forward port 500 to your VPN gateway and then it maps the response from that port to a new external port instead of using the existing static NAT mapping? Since the remote port is now not 500 anymore strongSwan won't switch to remote port 4500: > Mar 27 15:47:35 stg-vault-zk04 charon: 16[IKE] local > host is behind NAT, sending keep alives > Mar 27 15:47:35 stg-vault-zk04 charon: 16[IKE] remote > host is behind NAT > Mar 27 15:47:35 stg-vault-zk04 charon: 16[IKE] > reinitiating already active tasks > Mar 27 15:47:35 stg-vault-zk04 charon: 16[IKE] > ISAKMP_VENDOR task > Mar 27 15:47:35 stg-vault-zk04 charon: 16[IKE] > MAIN_MODE task > Mar 27 15:47:35 stg-vault-zk04 charon: 16[ENC] > generating ID_PROT request 0 [ ID HASH ] > Mar 27 15:47:35 stg-vault-zk04 charon: 16[NET] sending > packet: from 172.17.128.86[4500] to 13.88.23.150[1031] (92 bytes) > > ^ we shouldn't be seeing traffic from 4500 to (1030->500)??? Correct, but the code that does the port switch currently checks if the remote port is 500 and only switches to 4500 if that's the case. On the other hand, if we ourselves used port 500 the remote port really can't be anything else but 500 (even if it is mapped to something else). Otherwise, we wouldn't have been able to send a message to it as we only add a non-ESP marker if neither port is 500, so if 1031 was not port 500 our IKE messages would have been processed as ESP messages. > Mar 27 15:47:35 stg-vault-zk06 charon: 05[NET] <80> received packet: from > 54.186.244.242[500] to 10.0.0.59[500] (160 bytes) > Mar 27 15:47:35 stg-vault-zk06 charon: 05[CFG] <80> looking for an ike config > for 10.0.0.59...54.186.244.242 > Mar 27 15:47:35 stg-vault-zk06 charon: 05[CFG] <80> candidate: > 10.0.0.59...54.186.244.242, prio 3100 > Mar 27 15:47:35 stg-vault-zk06 charon: 05[CFG] <80> found matching ike > config: 10.0.0.59...54.186.244.242 with prio 3100 > Mar 27 15:47:35 stg-vault-zk06 charon: 05[IKE] <80> 54.186.244.242 is > initiating a Main Mode IKE_SA > Mar 27 15:47:35 stg-vault-zk06 charon: 05[NET] <80> sending packet: from > 10.0.0.59[500] to 54.186.244.242[500] (140 bytes) > Mar 27 15:47:35 stg-vault-zk06 charon: 10[NET] <80> received packet: from > 54.186.244.242[500] to 10.0.0.59[500] (524 bytes) > Mar 27 15:47:35 stg-vault-zk06 charon: 10[CFG] <80> candidate > "stg-vault-zk04_0", match: 1/1/3100 (me/other/ike) > Mar 27 15:47:35 stg-vault-zk06 charon: 10[IKE] <80> no shared key found for > '10.0.0.59'[10.0.0.59] - '(null)'[54.186.244.242] > > ^ I don't understand why this is '(null)' That's normal for IKEv1 as there is no remote identity yet when looking up the PSK (unless you configured one in a config and that config was found based on the IP addresses). > Mar 27 15:47:35 stg-vault-zk06 charon: 10[NET] <80> sending packet: from > 10.0.0.59[500] to 54.186.244.242[500] (524 bytes) > Mar 27 15:47:35 stg-vault-zk06 charon: 03[NET] sending packet: from > 10.0.0.59[500] to 54.186.244.242[4500] (36 bytes) > > ^ I don't know why this packet went from 500 to 4500 Because it received it on that port. But it's strange that this even works. The initiator uses port 4500 and sends to port 1031, so it should add a non-ESP marker. However, as responder the non-ESP marker is currently only stripped from the packet if neither port is 500. Here the responder's local port is 500, so the marker is not removed and parsing the IKE header should fail. Did you patch that? If not, what version are you using? > Mar 27 15:47:35 stg-vault-zk06 charon: 03[NET] received unsupported IKE > version 8.14 from 54.186.244.242, sending INVALID_MAJOR_VERSION > Mar 27 15:47:35 stg-vault-zk06 charon: 15[NET] received unencrypted > informational: from 54.186.244.242[4500] to 10.0.0.59[500] > > ^ at this point I believe we're getting ESP-in-UDP packets to 1031->500. Yep. I pushed a patch to the port-float branch that might help. And as a workaround you could just initiate the connection directly to port 4500 (remote_port=4500), and from port 4500 (local_port=4500). See [1]. Regards, Tobias [1] https://wiki.strongswan.org/projects/strongswan/wiki/NatTraversal
