[strongSwan] ipsec+gre with strongswan-lancom
Manu
manuprivat at gmx.de
Mon Mar 6 10:03:05 CET 2017
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
More information about the Users
mailing list