[strongSwan] ipsec+gre with strongswan-lancom
Noel Kuntze
noel at familie-kuntze.de
Mon Mar 6 23:03:43 CET 2017
The proper way is to configure a dhcp relay on the LANCOM router and point it at the DHCP server in your Linux server side.
But make sure you serve a different subnet to the LANCOM router than to your local subnet.
You need to do policy based routing on the LANCOM side and configure it to route all traffic from the subnet
the LANCOM uses in its LAN to the Linux server. On the Linux server, you need to add a route to the LANCOM's LAN
subnet to the main routing table.
On 06.03.2017 10:03, Manu wrote:
> Hi Noel,
>
> thank you very much for pointing me in the correct direction!!!
> Now, I successfully established the tunnel between both public IPs and avoided those 193.x.x.x IPs completely.
> Also traffic is possible to route through the tunnel!
>
> My test scenario now:
> Lancom:
> WAN: 192.168.0.177/24
> LAN: 172.16.0.1/24
>
> Linux-Server:
> WAN: 192.168.0.79/24
> LAN: 10.0.0.1/8
>
> Now, I would like to serve clients behind Lancom LAN with DHCP-Leases from Linux-Server, and all the traffic from clients from Lancom LAN should also be routed through the tunnel. Central break-out should be on linux-server again.
> Is this possible at all?
> Any help would be nice :-)
>
> BR Manu
>
>
>
> Am 02.03.2017 um 18:46 schrieb Noel Kuntze:
>> You did a couple of things wrong.
>> I'm going to start with the outer most layers and then work towards the actual routing in the GRE tunnel.
>>
>> 1. Your SA only needs to protect GRE traffic and you don't need to specify any of the IPs or subnets
>> in the GRE tunnel in the IPsec policies. It is actually working against you.
>> You can try making an actual transport mode tunnel that protects GRE packets or a tunnel mode
>> tunnel between the public IPs that protects GRE packets.
>> Then set up the GRE tunnel between those public IPs (or the local IP that is
>> part of the TS and the remote IP that is part of the TS). Then add that fancy IP
>> to the GRE tunnel device and then add the route to the remote subnet to the main routing table.
>>
>>
>> Short: How-To
>> 1. Fix TS to be between the public IPs and to protect GRE packets (Latter part is optional and
>> it will work just fine even if you protect all the traffic between the two peers)
>> 2. (NOTE: Unless you do dynamic routing, you don't need any virtual IPs on the GRE tunnels. So if you don't do dynamic routing, skip this.)
>> Create GRE tunnel between the public IPs. Add your own virtual IP (/32) to your local end of the tunnel (ip address add ...)
>> Route the remote side's virtual IP (/32) through the tunnel (ip route add ...).
>> 3. Add the necessary routes to the remote subnets to your end of the tunnel. Do the same vice versa on the remote.
>> 4. Profit.
>>
>>> Lancom:
>>> WAN:192.168.203.156/24
>>> LAN: 10.0.0.211/24
>>>
>>> Linux-Server:
>>> WAN: 192.168.0.79/24
>>> LAN: 10.0.0.1/24
>>>
>>> I know that maybe IP-ranges seems to be strange on LAN interfaces, but what I am planning to solve is to serve clients behind Lancom with DHCP leases from Linux servers.
>>> DHCP server is already running on LAN interface from Linux server.
>>> But in the first step I would be glad, to get a Ping successfully routed through tunnel...
>> You must not break that subnet apart. If you do that, the hosts on either fragment of the subnet will not be able to communicate
>> with the other side, because the routes the hosts have is an onlink route, not a nexthop (via) route. Even if they did, you'd get
>> triangular routing and that's pretty bad. Just use different subnets instead and a DHCP relay.
>>
>>> ip tunnel add ipsec0 local 193.1.1.2 remote 193.1.1.1 mode gre
>>> ip link set ipsec0 up
>>> ip route add 10.0.0.0/24 dev ipsec0
>>> ip route add 193.1.1.1/32 dev ipsec0
>>>
>>> ip -s tunnel show ipsec0
>>> ~ # ip -s tunnel show ipsec0
>>> ipsec0: gre/ip remote 193.1.1.1 local 193.1.1.2 ttl inherit
>>> RX: Packets Bytes Errors CsumErrs OutOfSeq Mcasts
>>> 0 0 0 0 0 0
>>> TX: Packets Bytes Errors DeadLoop NoRoute NoBufs
>>> 0 0 115 0 115 0
>>>
>>> -> pointing to NoRoute pakets, but don't recognize what is wrong?!
>> You just did circular routing. The remote peer of the GRE tunnel is reachable over the gre tunnel itself.
>> The packets to the remote peer would go into the gre tunnel and then the GRE packets would go into the GRE tunnel.
>> Luckily, the kernel recognized that and prevents you from doing that.
>>
>>> ip tunnel add ipsec0 local 193.1.1.2 remote 193.1.1.1 mode gre
>>> ip route add 193.1.1.1/32 dev ipsec0
>> Circular routing. Don't do that.
>>
>>> -A FORWARD -m policy --dir out --pol ipsec --proto ipv6-crypt -j ACCEPT
>> What is ipv6-crypt? The man page here on Linux 4.4.52-lts only mentions ah, esp and ipcomp.
>> Your rule set breaks ICMP error reporting. You need to rewrite it based on the example
>> rule set for an edge-router[1] or a host[2].
>>
>>
>>> ###################################################
>>>
>>> Routing:
>>> 0.0.0.0 192.168.0.11 0.0.0.0 UG 0 0 0 eth0
>>> 10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 ipsec0
>>> 192.168.0.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0
>>> 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
>>> 193.1.1.1 0.0.0.0 255.255.255.255 UH 0 0 0 ipsec0
>> Don't use ifconfig, route or netstat. Use iproute2 (ip address, ip rule, ip route, ...) and ss.
>> The net-tools haven't been maintained since the early 2000s and don't support any of the fancy
>> new stuff that is required for IPsec and the features that strongSwan use. You won't be able
>> to deal with it using the net-tools.
>>
>>> IPsec status:
>>> Status of IKE charon daemon (strongSwan 5.5.1, Linux 3.16.2, i686):
>>> uptime: 17 minutes, since Feb 27 09:38:50 2017
>>> malloc: sbrk 299008, mmap 0, used 161544, free 137464
>>> worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 2
>>> loaded plugins: charon aes des rc2 sha2 sha1 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem fips-prf gmp xcbc cmac hmac attr kernel-netlink resolve socket-default stroke vici updown xauth-generic
>>> Listening IP addresses:
>>> 192.168.0.79
>>> 192.168.2.1
>>> 10.0.0.1
>>> Connections:
>>> net-net: 192.168.0.79...192.168.203.156 IKEv1
>>> net-net: local: [193.1.1.2] uses pre-shared key authentication
>>> net-net: remote: [193.1.1.1] uses pre-shared key authentication
>>> net-net: child: 193.1.1.2/32 === 193.1.1.1/32 TUNNEL
>>> Security Associations (1 up, 0 connecting):
>>> net-net[1]: ESTABLISHED 17 minutes ago, 192.168.0.79[193.1.1.2]...192.168.203.156[193.1.1.1]
>>> net-net[1]: IKEv1 SPIs: 0ed2f0323516cdc9_i* e306944936d04d17_r, pre-shared key reauthentication in 26 minutes
>>> net-net[1]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
>>> net-net{1}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: c93984d3_i 3d7dfb5e_o
>>> net-net{1}: AES_CBC_128/HMAC_SHA1_96/MODP_1024, 0 bytes_i, 0 bytes_o, rekeying in 32 minutes
>>> net-net{1}: 193.1.1.2/32 === 193.1.1.1/32
>>>
>> As previously mentioned, wrong TS.
>>
>>> #################################################
>>> ipsec.conf:
>>> config setup
>>>
>>> conn %default
>>> keyexchange=ikev1
>>> authby=secret
>>> left=192.168.0.79
>>> leftid=193.1.1.2
>>> leftsubnet=193.1.1.2/32
>>> leftfirewall=yes
>>> auto=start
>>>
>>> conn net-net
>>> right=192.168.203.156
>>> rightsubnet=193.1.1.1/32
>>> rightid=193.1.1.1
>>> ike=aes-sha1-modp1024
>>> esp=aes-sha1-modp1024
>>> ikelifetime=3600s
>>> keylife=3600s
>> Use auto=route, not auto=start.
>>
>>> What I have also tried is setting up a bridge instead of commands above - but also no success with that:
>>> ip link add gretap1 type gretap local 193.1.1.2 remote 193.1.1.1
>>> ip link set dev gretap1 up
>>>
>>> brctl addbr br0
>>> brctl addif br0 gretap1
>>> brctl addif br0 eth2
>>> ip addr add 10.0.0.1/24 dev br0
>>> ip link set br0 up
>> Of course not. You still did the things wrong that I mentioned above and GRETAP encapsulates ETHERNET FRAMES
>> NOT IP PACKETS. Even if you configured the TS correctly and got a usable CHILD_SA up, the remote peer would just
>> drop the GRETAP packets, because the packets don't contain valid IP packets.
>>
>>
>>> furthermore tried with that rule:
>>>
>>> iptables -t nat -A POSTROUTING -o ipsec0 -j SNAT --to-source 193.1.1.2
>>>
>>> and got tcpdump result:
>>> ~ # tcpdump -i ipsec0 -vvn
>>> tcpdump: WARNING: ipsec0: no IPv4 address assigned
>>> tcpdump: listening on ipsec0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
>>> 10:24:16.964011 IP (tos 0x0, ttl 64, id 49218, offset 0, flags [DF], proto ICMP (1), length 84)
>>> 193.1.1.2 > 10.0.0.211: ICMP echo request, id 55629, seq 13, length 64
>>> 10:24:17.972005 IP (tos 0x0, ttl 64, id 49294, offset 0, flags [DF], proto ICMP (1), length 84)
>>> 193.1.1.2 > 10.0.0.211: ICMP echo request, id 55629, seq 14, length 64
>>>
>>> ###############################################
>> Of course not, because it's not your problem.
>>
>> [1] https://github.com/QueuingKoala/netfilter-samples/tree/master/rules-edge-router
>> [2] https://github.com/QueuingKoala/netfilter-samples/tree/master/rules-host
>>
>> On 27.02.2017 10:35, Manu wrote:
>>> Hi all,
>>>
>>> I would like to set up an IPsec connection with GRE tunnel to route all traffic from a Lancom router to a Linux server.
>>> I successfully installed VPN and GRE between two Lancoms - this works fine.
>>> Now I replaced one Lancom with a Linux server and installed strongswan 5.5.1.
>>> I got successfully established IPsec connection, but routing traffic is not working!?
>>>
>>> Lancom:
>>> WAN:192.168.203.156/24
>>> LAN: 10.0.0.211/24
>>>
>>> Linux-Server:
>>> WAN: 192.168.0.79/24
>>> LAN: 10.0.0.1/24
>>>
>>> I know that maybe IP-ranges seems to be strange on LAN interfaces, but what I am planning to solve is to serve clients behind Lancom with DHCP leases from Linux servers.
>>> DHCP server is already running on LAN interface from Linux server.
>>> But in the first step I would be glad, to get a Ping successfully routed through tunnel...
>>>
>>> You can find my configuration and output from status commands below.
>>> If I missed something to write, please let me know!
>>> Any help would be greatly appreciated. Thx in advance.
>>>
>>> BR
>>> Manu
>>>
>>> #########################################################
>>> iptables:
>>> # Generated by iptables-save v1.4.21 on Mon Feb 27 09:49:14 2017
>>> *raw
>>> :PREROUTING ACCEPT [27390:33401494]
>>> :OUTPUT ACCEPT [14840:1301522]
>>> COMMIT
>>> # Completed on Mon Feb 27 09:49:14 2017
>>> # Generated by iptables-save v1.4.21 on Mon Feb 27 09:49:14 2017
>>> *nat
>>> :PREROUTING ACCEPT [1320:185699]
>>> :INPUT ACCEPT [163:41196]
>>> :OUTPUT ACCEPT [607:40276]
>>> :POSTROUTING ACCEPT [11:780]
>>> COMMIT
>>> # Completed on Mon Feb 27 09:49:14 2017
>>> # Generated by iptables-save v1.4.21 on Mon Feb 27 09:49:14 2017
>>> *mangle
>>> :PREROUTING ACCEPT [27389:33401416]
>>> :INPUT ACCEPT [26518:33293236]
>>> :FORWARD ACCEPT [107:8132]
>>> :OUTPUT ACCEPT [14840:1301522]
>>> :POSTROUTING ACCEPT [14947:1309654]
>>> COMMIT
>>> # Completed on Mon Feb 27 09:49:14 2017
>>> # Generated by iptables-save v1.4.21 on Mon Feb 27 09:49:14 2017
>>> *filter
>>> :INPUT DROP [0:0]
>>> :FORWARD DROP [0:0]
>>> :OUTPUT DROP [0:0]
>>> -A INPUT -m policy --dir in --pol ipsec --proto ipv6-crypt -j ACCEPT
>>> -A INPUT -p 47 -j ACCEPT
>>> -A INPUT -p ipv6-auth -j ACCEPT
>>> -A INPUT -p ipv6-crypt -j ACCEPT
>>> -A INPUT -p ipv6-crypt -j ACCEPT
>>> -A INPUT -p udp -m udp --dport 4500 -j ACCEPT
>>> -A INPUT -p udp -m udp --dport 500 -j ACCEPT
>>> -A INPUT -p udp -m udp --dport 87 -j ACCEPT
>>> -A INPUT -j ACCEPT
>>> -A FORWARD -s 193.1.1.1/32 -d 193.1.1.2/32 -i eth0 -m policy --dir in --pol ipsec --reqid 1 --proto ipv6-crypt -j ACCEPT
>>> -A FORWARD -s 193.1.1.2/32 -d 193.1.1.1/32 -o eth0 -m policy --dir out --pol ipsec --reqid 1 --proto ipv6-crypt -j ACCEPT
>>> -A FORWARD -p 47 -m policy --dir out --pol ipsec -j ACCEPT
>>> -A FORWARD -p 47 -m policy --dir in --pol ipsec -j ACCEPT
>>> -A FORWARD -m policy --dir out --pol ipsec --proto ipv6-crypt -j ACCEPT
>>> -A FORWARD -m policy --dir in --pol ipsec --proto ipv6-crypt -j ACCEPT
>>> -A FORWARD -j ACCEPT
>>> -A OUTPUT -p ipv6-auth -j ACCEPT
>>> -A OUTPUT -p ipv6-crypt -j ACCEPT
>>> -A OUTPUT -p ipv6-crypt -j ACCEPT
>>> -A OUTPUT -p udp -m udp --dport 4500 -j ACCEPT
>>> -A OUTPUT -p udp -m udp --dport 500 -j ACCEPT
>>> -A OUTPUT -p udp -m udp --dport 87 -j ACCEPT
>>> -A OUTPUT -m policy --dir out --pol ipsec --proto ipv6-crypt -j ACCEPT
>>> -A OUTPUT -p 47 -j ACCEPT
>>> -A OUTPUT -j ACCEPT
>>> COMMIT
>>> # Completed on Mon Feb 27 09:49:14 2017
>>>
>>>
>>>
>>> ###################################################
>>>
>>> Routing:
>>> 0.0.0.0 192.168.0.11 0.0.0.0 UG 0 0 0 eth0
>>> 10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 ipsec0
>>> 192.168.0.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0
>>> 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
>>> 193.1.1.1 0.0.0.0 255.255.255.255 UH 0 0 0 ipsec0
>>>
>>> ###################################################
>>> IPsec status:
>>> Status of IKE charon daemon (strongSwan 5.5.1, Linux 3.16.2, i686):
>>> uptime: 17 minutes, since Feb 27 09:38:50 2017
>>> malloc: sbrk 299008, mmap 0, used 161544, free 137464
>>> worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 2
>>> loaded plugins: charon aes des rc2 sha2 sha1 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem fips-prf gmp xcbc cmac hmac attr kernel-netlink resolve socket-default stroke vici updown xauth-generic
>>> Listening IP addresses:
>>> 192.168.0.79
>>> 192.168.2.1
>>> 10.0.0.1
>>> Connections:
>>> net-net: 192.168.0.79...192.168.203.156 IKEv1
>>> net-net: local: [193.1.1.2] uses pre-shared key authentication
>>> net-net: remote: [193.1.1.1] uses pre-shared key authentication
>>> net-net: child: 193.1.1.2/32 === 193.1.1.1/32 TUNNEL
>>> Security Associations (1 up, 0 connecting):
>>> net-net[1]: ESTABLISHED 17 minutes ago, 192.168.0.79[193.1.1.2]...192.168.203.156[193.1.1.1]
>>> net-net[1]: IKEv1 SPIs: 0ed2f0323516cdc9_i* e306944936d04d17_r, pre-shared key reauthentication in 26 minutes
>>> net-net[1]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
>>> net-net{1}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: c93984d3_i 3d7dfb5e_o
>>> net-net{1}: AES_CBC_128/HMAC_SHA1_96/MODP_1024, 0 bytes_i, 0 bytes_o, rekeying in 32 minutes
>>> net-net{1}: 193.1.1.2/32 === 193.1.1.1/32
>>>
>>>
>>> #################################################
>>> ipsec.conf:
>>> config setup
>>>
>>> conn %default
>>> keyexchange=ikev1
>>> authby=secret
>>> left=192.168.0.79
>>> leftid=193.1.1.2
>>> leftsubnet=193.1.1.2/32
>>> leftfirewall=yes
>>> auto=start
>>>
>>> conn net-net
>>> right=192.168.203.156
>>> rightsubnet=193.1.1.1/32
>>> rightid=193.1.1.1
>>> ike=aes-sha1-modp1024
>>> esp=aes-sha1-modp1024
>>> ikelifetime=3600s
>>> keylife=3600s
>>>
>>> #################################################
>>>
>>> ip tunnel add ipsec0 local 193.1.1.2 remote 193.1.1.1 mode gre
>>> ip link set ipsec0 up
>>> ip route add 10.0.0.0/24 dev ipsec0
>>> ip route add 193.1.1.1/32 dev ipsec0
>>>
>>>
>>> ip -s tunnel show ipsec0
>>> ~ # ip -s tunnel show ipsec0
>>> ipsec0: gre/ip remote 193.1.1.1 local 193.1.1.2 ttl inherit
>>> RX: Packets Bytes Errors CsumErrs OutOfSeq Mcasts
>>> 0 0 0 0 0 0
>>> TX: Packets Bytes Errors DeadLoop NoRoute NoBufs
>>> 0 0 115 0 115 0
>>>
>>> -> pointing to NoRoute pakets, but don't recognize what is wrong?!
>>>
>>>
>>> ################################################
>>> ################################################
>>>
>>> What I have also tried is setting up a bridge instead of commands above - but also no success with that:
>>> ip link add gretap1 type gretap local 193.1.1.2 remote 193.1.1.1
>>> ip link set dev gretap1 up
>>>
>>> brctl addbr br0
>>> brctl addif br0 gretap1
>>> brctl addif br0 eth2
>>> ip addr add 10.0.0.1/24 dev br0
>>> ip link set br0 up
>>>
>>> ################################################
>>> furthermore tried with that rule:
>>>
>>> iptables -t nat -A POSTROUTING -o ipsec0 -j SNAT --to-source 193.1.1.2
>>>
>>> and got tcpdump result:
>>> ~ # tcpdump -i ipsec0 -vvn
>>> tcpdump: WARNING: ipsec0: no IPv4 address assigned
>>> tcpdump: listening on ipsec0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
>>> 10:24:16.964011 IP (tos 0x0, ttl 64, id 49218, offset 0, flags [DF], proto ICMP (1), length 84)
>>> 193.1.1.2 > 10.0.0.211: ICMP echo request, id 55629, seq 13, length 64
>>> 10:24:17.972005 IP (tos 0x0, ttl 64, id 49294, offset 0, flags [DF], proto ICMP (1), length 84)
>>> 193.1.1.2 > 10.0.0.211: ICMP echo request, id 55629, seq 14, length 64
>>>
>>> ###############################################
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.strongswan.org
>>> https://lists.strongswan.org/mailman/listinfo/users
>
>
--
Mit freundlichen Grüßen/Kind Regards,
Noel Kuntze
GPG Key ID: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 866 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20170306/7175266c/attachment.sig>
More information about the Users
mailing list