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
[email protected]
https://lists.strongswan.org/mailman/listinfo/users
