[strongSwan] Succesful IPSec connection, but how to access computer on other side?
Noel Kuntze
noel at familie-kuntze.de
Fri Jun 12 16:42:29 CEST 2015
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hello Nicolas,
i already described the next step in my previous emails. Figure out what the other side has problems with.
So you should go and ask the admins of that other company to look through the logs.
There is no way to tell what the CISCO device's problem is from your position.
IPsec is policy based, not route based. So you won't get a device.
IPsec policies will steal the packets from the network stack
after the routing decision has been made and will mangle them, basicly
ignoring the routing decision. Read the introduction to strongswan[1] and split-tunneling[2] articles
on the wiki for more information.
Also, your encryption domain settings are incompatible with your local subnet. Read the aforementioned articles
for information. Possible solutions for this is are the use of the NETMAP target in iptables (to map your
LAN to the encryption domain given to you by the other company), so you can actually use the tunnel once it is up,
or talking to the guys about the possibility of changing the tunnel configuration so you can use your LAN directly, without mapping
it onto another subnet.
[1] https://wiki.strongswan.org/projects/strongswan/wiki/IntroductionTostrongSwan
[2] https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunneling
Mit freundlichen Grüßen/Kind Regards,
Noel Kuntze
GPG Key ID: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
Am 12.06.2015 um 16:26 schrieb Nicolas Göddel:
> Hi Noel,
>
> It's good to know that my config is fine. Thank you.
>
> I have no physical access to the other side. There are other administrators from a bigger company. They want to have an IPSec tunnel between them and us so that we can access their ticket system. So I had to learn about IPSec and found strongswan. :)
>
> What would be the next step after the configurations on both sides are correct? How can I route traffic from my Lubuntu (192.168.1.152) through the IPSec tunnel to reach an address in their encryption domain?
> Has this something do to with the 'auto=ignore|add|route|start' parameter?
> How should the output of 'ipsec up <conn>' look like if all went right?
>
> Sorry for my possibly dumb questions.
>
> Kind Regards,
> Nicolas
>
> Am 12.06.2015 um 12:55 schrieb Noel Kuntze:
> >
>> Hello Nicolas,
>>
>> Well, I don't know. Maybe it's because the API that "ipsec" uses to communicate with charon
>> actually doesn't return any success or failure value, but only text output.
>>
>> Any more verbose output of your own side will not help you.
>> You need to get to the other side and check what kinds of problems it has.
>> Your config looks fine.
>>
>> Mit freundlichen Grüßen/Kind Regards,
>> Noel Kuntze
>>
>> GPG Key ID: 0x63EC6658
>> Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
>>
>> Am 12.06.2015 um 12:30 schrieb Nicolas Göddel:
>> > Hi Noel,
>>
>> > why is 'ipsec up union' saying that the connection was established successfully?
>>
>> > Here is the output of 'ip route' and 'ip address':
>>
>> > root at vpn-server:~# ip route
>> > default via 176.94.x.x dev eth1
>> > 176.94.x.x/29 dev eth1 proto kernel scope link src 176.94.x.x metric 1
>> > 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.152 metric 1
>> > root at vpn-server:~# ip address
>> > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
>> > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>> > inet 127.0.0.1/8 scope host lo
>> > valid_lft forever preferred_lft forever
>> > inet6 ::1/128 scope host
>> > valid_lft forever preferred_lft forever
>> > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
>> > link/ether c4:6e:1f:06:xx:xx brd ff:ff:ff:ff:ff:ff
>> > inet 192.168.1.152/24 brd 192.168.1.255 scope global eth0
>> > valid_lft forever preferred_lft forever
>> > inet6 fe80::c66e:1fff:xxxx:xxxx/64 scope link
>> > valid_lft forever preferred_lft forever
>> > 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
>> > link/ether 00:1b:fc:90:xx:xx brd ff:ff:ff:ff:ff:ff
>> > inet 176.94.x.x/29 brd 176.94.x.x scope global eth1
>> > valid_lft forever preferred_lft forever
>> > inet6 fe80::21b:fcff:xxxx:xxxx/64 scope link
>> > valid_lft forever preferred_lft forever
>>
>> > Would it help if there were a more verbose output? How can I achieve this?
>>
>> > BTW this is the form I got from the other side so that I can configure my side:
>>
>> > IKE Phase 1
>> > Mode: Main Mode
>> > Authentication Method: Preshared Key
>> > Encryption: AES256
>> > Hashing Algorithm: SHA256
>> > Lifetime seconds: 86400s
>> > Diffie-Hellman group: DH Group 14
>>
>> > Site A
>> > Gateway IP: 83.136.y.y
>> > Gateway Identification: 83.136.y.y
>>
>> > Site B
>> > Gateway IP: 176.94.x.x
>> > Gateway Identification: 176.94.x.x
>>
>> > IKE Phase 2
>> > Protocol: ESP
>> > Encapsulation Mode: Tunnel
>> > Encryption: AES256
>> > Hashing Algorithm: SHA256
>> > Lifetime seconds: 3600s
>> > Lifetime kbytes: 4608000kb
>> > Perfect forward secrecy: DH Group 14
>>
>> > Site A Encryption Domain: 10.251.0.0/16
>> > Site B Encryption Domain: 10.100.1.0/24
>>
>> > Maybe there is also a failure in my configuration.
>>
>> > Best Regards,
>> > Nicolas
>>
>> > Am 09.06.2015 um 17:54 schrieb Noel Kuntze:
>> >>
>> >> Hello Nicolas,
>> >>
>> >> Output of "route" or "ifconfig" is useless. Please only post output
>> >> that "iproute2" produces. E.g: ip route, ip address
>> >>
>> >> The connection doesn't get initiated correctly. The other side deletes the IKE SA
>> >> after it gets established:
>> >>
>> >>> received packet: from 83.136.y.y[500] to 176.94.x.x[500] (108 bytes)
>> >>> parsed INFORMATIONAL_V1 request 2733943088 [ HASH D ]
>> >>> received DELETE for IKE_SA union[1]
>> >>> deleting IKE_SA union[1] between 176.94.x.x[176.94.x.x]...83.136.y.y[83.136.y.y]
>> >>> initiating Main Mode IKE_SA union[2] to 83.136.y.y
>> >>
>> >> Examine the other side and find out why that happens.
>> >>
>> >>
>> >> Mit freundlichen Grüßen/Kind Regards,
>> >> Noel Kuntze
>> >>
>> >> GPG Key ID: 0x63EC6658
>> >> Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
>> >>
>> >> Am 09.06.2015 um 14:11 schrieb Nicolas Göddel:
>> >>> Hi,
>> >>
>> >>> I am new to the topic VPN, IPSec, route, iptables, etc.
>> >>
>> >>> I have the scenario mentioned in the attachment. My IPSec Gateway is a Lubuntu with two network interfaces. eth0 is connected to the internal LAN. There is a switch which connects a few Windows computers with a Cisco RV042 router and the Lubuntu (IPSec Gateway). The Cisco gives internet acces over a fast internet connection and has DHCP enabled so that all Windows computers get their IP address from this router and are able to use internet. At the moment Lubuntu is configured to a static IP within the Subnet 192.168.1.0/24. On eth1 there is connected a second modem with the static IP 176.94.x.x which should be used to create a Site-to-Site IPSec connection to an other company.
>> >>
>> >>> _route looks like this:_
>> >>
>> >>> root at vpn-server:~# LANG=C route
>> >>> Kernel IP routing table
>> >>> Destination Gateway Genmask Flags Metric Ref Use Iface
>> >>> default business-176-09 0.0.0.0 UG 0 0 0 eth1
>> >>> 176.94.52.88 * 255.255.255.248 U 1 0 0 eth1
>> >>> 192.168.1.0 * 255.255.255.0 U 1 0 0 eth0
>> >>
>> >>> _This /etc/ipsec.conf__:_
>> >>
>> >>> config setup
>> >>> charondebug="cfg 2, dmn 2, ike 2, net 2"
>> >>
>> >>> conn %default
>> >>
>> >>> conn union
>> >>> left=176.94.x.x
>> >>> leftsubnet=10.100.1.0/24
>> >>> leftsourceip=10.100.1.1
>> >>> leftfirewall=yes
>> >>> right=83.136.y.y
>> >>> rightsubnet=10.251.0.0/16
>> >>> auto=add
>> >>> ikelifetime=24h
>> >>> lifetime=1h
>> >>> type=tunnel
>> >>> lifebytes=4718592000
>> >>> ike=aes256-sha256-modp2048
>> >>> esp=aes256-sha256-modp2048
>> >>> authby=psk
>> >>> keyexchange=ikev1
>> >>> lefthostaccess=yes
>> >>
>> >>> _This is /etc/strongswan.conf__:_
>> >>
>> >>> charon {
>> >>> load_modular = yes
>> >>> plugins {
>> >>> include strongswan.d/charon/*.conf
>> >>> }
>> >>> }
>> >>
>> >>> include strongswan.d/*.conf
>> >>
>> >>> _This is ifconfig -a:_
>> >>
>> >>> root at vpn-server:~# ifconfig -a
>> >>> eth0 Link encap:Ethernet Hardware Adresse c4:6e:1f:06:10:90
>> >>> inet Adresse:192.168.1.152 Bcast:192.168.1.255 Maske:255.255.255.0
>> >>> inet6-Adresse: fe80::c66e:1fff:fe06:1090/64 Gültigkeitsbereich:Verbindung
>> >>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
>> >>> RX-Pakete:1355634 Fehler:0 Verloren:360 Überläufe:0 Fenster:0
>> >>> TX-Pakete:12684 Fehler:0 Verloren:0 Überläufe:0 Träger:0
>> >>> Kollisionen:0 Sendewarteschlangenlänge:1000
>> >>> RX-Bytes:113088435 (113.0 MB) TX-Bytes:1505232 (1.5 MB)
>> >>
>> >>> eth1 Link encap:Ethernet Hardware Adresse 00:1b:fc:90:80:51
>> >>> inet Adresse:176.94.x.x Bcast:176.94.x.x Maske:255.255.255.248
>> >>> inet6-Adresse: fe80::21b:fcff:xxxx:xxxx/64 Gültigkeitsbereich:Verbindung
>> >>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
>> >>> RX-Pakete:1955017 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
>> >>> TX-Pakete:1898517 Fehler:0 Verloren:0 Überläufe:0 Träger:0
>> >>> Kollisionen:0 Sendewarteschlangenlänge:1000
>> >>> RX-Bytes:472209413 (472.2 MB) TX-Bytes:443885596 (443.8 MB)
>> >>
>> >>> lo Link encap:Lokale Schleife
>> >>> inet Adresse:127.0.0.1 Maske:255.0.0.0
>> >>> inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
>> >>> UP LOOPBACK RUNNING MTU:65536 Metrik:1
>> >>> RX-Pakete:10137 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
>> >>> TX-Pakete:10137 Fehler:0 Verloren:0 Überläufe:0 Träger:0
>> >>> Kollisionen:0 Sendewarteschlangenlänge:0
>> >>> RX-Bytes:1341831 (1.3 MB) TX-Bytes:1341831 (1.3 MB)
>> >>
>> >>> _This is starting ipsec:_
>> >>
>> >>> root at vpn-server:~# ipsec start
>> >>> Starting strongSwan 5.1.2 IPsec [starter]...
>> >>> root at vpn-server:~# ipsec up union
>> >>> initiating Main Mode IKE_SA union[1] to 83.136.y.y
>> >>> generating ID_PROT request 0 [ SA V V V V ]
>> >>> sending packet: from 176.94.x.x[500] to 83.136.y.y[500] (196 bytes)
>> >>> received packet: from 83.136.y.y[500] to 176.94.x.x[500] (108 bytes)
>> >>> parsed ID_PROT response 0 [ SA V ]
>> >>> received NAT-T (RFC 3947) vendor ID
>> >>> generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
>> >>> sending packet: from 176.94.x.x[500] to 83.136.y.y[500] (396 bytes)
>> >>> received packet: from 83.136.y.y[500] to 176.94.x.x[500] (456 bytes)
>> >>> parsed ID_PROT response 0 [ KE No V V V V NAT-D NAT-D ]
>> >>> received Cisco Unity vendor ID
>> >>> received DPD vendor ID
>> >>> received unknown vendor ID: 75:37:a8:c7:39:54:ff:f2:a8:f6:8d:a3:d4:0b:63:11
>> >>> received XAuth vendor ID
>> >>> generating ID_PROT request 0 [ ID HASH ]
>> >>> sending packet: from 176.94.x.x[500] to 83.136.y.y[500] (92 bytes)
>> >>> received packet: from 83.136.y.y[500] to 176.94.x.x[500] (92 bytes)
>> >>> parsed ID_PROT response 0 [ ID HASH ]
>> >>> IKE_SA union[1] established between 176.94.x.x[176.94.x.x]...83.136.y.y[83.136.y.y]
>> >>> scheduling reauthentication in 85375s
>> >>> maximum IKE_SA lifetime 85915s
>> >>> generating TRANSACTION request 247522367 [ HASH CPRQ(ADDR DNS) ]
>> >>> sending packet: from 176.94.x.x[500] to 83.136.y.y[500] (92 bytes)
>> >>> received packet: from 83.136.y.y[500] to 176.94.x.x[500] (108 bytes)
>> >>> parsed INFORMATIONAL_V1 request 2733943088 [ HASH D ]
>> >>> received DELETE for IKE_SA union[1]
>> >>> deleting IKE_SA union[1] between 176.94.x.x[176.94.x.x]...83.136.y.y[83.136.y.y]
>> >>> initiating Main Mode IKE_SA union[2] to 83.136.y.y
>> >>> generating ID_PROT request 0 [ SA V V V V ]
>> >>> sending packet: from 176.94.x.x[500] to 83.136.y.y[500] (196 bytes)
>> >>> connection 'union' established successfully
>> >>> root at vpn-server:~# ipsec status
>> >>> Security Associations (1 up, 0 connecting):
>> >>> union[1627]: CONNECTING, 176.94.x.x[%any]...83.136.y.y[%any]
>> >>
>> >>> Now I want to be able to ping the computer on the other side with the IP address 10.251.232.75 from Lubuntu. What have I to do?
>> >>> Later I want to be able to connect from any Windows PC to the 10.251.232.75. What have I to do then?
>> >>> I can assume that the other side is configured correctly, so that I should be able to ping 10.251.232.75 from my side. But first I have to do things right on my side.
>> >>
>> >>> I thought strongswan would create a virtual interface like openvpn does. I guess this way I would be able to use this virtual interface as gateway to the VPN/IPSec tunnel.
>> >>> What do I need, where can I read about this scenario? Do you need more information?
>> >>
>> >>> Thank you!
>> >>
>> >>> --
>> >>> ——————————————————————————————————————————————
>> >>> Homepage: http://freakscorner.de
>> >>> Facebook: http://www.facebook.com/Bastelkeller
>> >>> Twitter: http://twitter.com/freaks_corner
>> >>> Youtube: http://youtube.com/tubenic86
>> >>
>> >>
>> >>> _______________________________________________
>> >>> Users mailing list
>> >>> Users at lists.strongswan.org
>> >>> https://lists.strongswan.org/mailman/listinfo/users
>> >>
>> >>
>> >>
>>
>>
>> > --
>> > ——————————————————————————————————————————————
>> > Homepage: http://freakscorner.de
>> > Facebook: http://www.facebook.com/Bastelkeller
>> > Twitter: http://twitter.com/freaks_corner
>> > Youtube: http://youtube.com/tubenic86
>>
>>
> >
> >
>
>
> --
> ——————————————————————————————————————————————
> Homepage: http://freakscorner.de
> Facebook: http://www.facebook.com/Bastelkeller
> Twitter: http://twitter.com/freaks_corner
> Youtube: http://youtube.com/tubenic86
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJVeu/TAAoJEDg5KY9j7GZYhK8QAJ6oUzTt8bJUgbezmm9+6/2l
2SXIBJ9EEmX6CCnTIcSr7RlfUhGOD37eoIMSNM6LG5W740tmr7iz68f2GNMDares
Fv99ukwdUPokX2lelSoWO/Gm2fKageywFzF4Ibf+tN2GiHscV5mERF6I/6pfhgh7
1mf5EtbR/DMZTbyQqwOqo7tc32BaYA0Q1G2BJipPojJ4Mt2bFKQD+mUdFEEnDpJZ
pxT9RQaeHDd9J8I3KCaJFX/2n+MKZYBIHVwpI/O9nHh0ZMAGnJ40aXP+jndiWzy0
NB3/bf2pGiETr4zc6wBFSwf6IZhgFfMn9mm3Mc72jfBM/YVJ5iVg/Xvg2b4UG0Gs
Fp0TYahEWa+/C8zGtt1uCGTMSWlqvktmCEMPAOeEWKXc5OAiN65nc6u5OBsestJz
yKgWgDbHdIlCM41l8emo8iCOTfhInMG4Bhj+HW5i9jfFcX9mFI3u+bauxQZEpjPs
qmfxyp0XT5vHEDg8/0zqf7Nehgdq1Lcd8GyTLgau3GRUrpFBg9DOtNwDoSlYDQfi
3RdE2v24x3hL+4KqP0AOO3R1p1zvdyyD1MgbV3kCUlXcqHIccbDGG8Cbv8DTC0mZ
9FRwBugFEDPXyETx0l5NJjGtoGLL/80Wicr0M8hQU3XduLjrwmm1KzzyGLgnWtUY
VefSWBIz+pikxzZxhp97
=qVJI
-----END PGP SIGNATURE-----
More information about the Users
mailing list