Issue #3606
Using ipsec tunnel from "foreign" subnet
Description
Hello,
we have strongswan installed on a gateway / firewall computer running on debian buster with several network interfaces. It serves as default gateway for our internal LAN (eth1) to the internet. We managed to establish an ipsec tunnel to a fortigate firewall, using the network on eth2 as leftsubnet. I am able to ping through the tunnel from the gateway computer but not from any computer in the subnet on eth1. A computer connected to eth2 can ping through the tunnel. Is it at all possible to use the tunnel from a subnet that is not declared as leftsubnet which is thus not known to the other side of the tunnel (the fortigate firewall)?
This is the ipsec.conf:
# ipsec.conf - strongSwan IPsec configuration file
# basic configuration
config setup
# strictcrlpolicy=yes
# uniqueids = no
charondebug="all"
# Add connections here.
conn conn1
auto=start
type=tunnel
left=%defaultroute
leftid=222.333.444.555 (external IP debian machine)
leftsubnet=192.168.100.0/24
leftfirewall=yes
authby=secret
ike=aes256-md5-modp1536
keyexchange=ikev1
ikelifetime=8h
esp=aes256-md5-modp1536
keyingtries=5
lifetime=1h
pfs=yes
conn conn2
also=conn1
right=111.222.333.444 (external IP fortigate firewall)
rightsubnet=10.10.10.0/24
rightfirewall=yes
auto=start
ip route show table 220:
10.10.10.0/24 via 222.333.444.555 dev ppp1 proto static src 192.168.100.1
ip xfrm policy list:
src 192.168.100.0/24 dst 10.10.10.10/24
dir out priority 373887 ptype main
tmpl src 222.333.444.555 dst 111.222.333.444
proto esp spi 0xd6b9b49b reqid 1 mode tunnel
src 10.10.10.0/24 dst 192.168.100.0/24
dir fwd priority 373887 ptype main
tmpl src 111.222.333.444 dst 222.333.444.555
proto esp reqid 1 mode tunnel
src 10.10.10.0/24 dst 192.168.100.0/24
dir in priority 373887 ptype main
tmpl src 111.222.333.444 dst 222.333.444.555
proto esp reqid 1 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0 ptype main
src ::/0 dst ::/0
socket in priority 0 ptype main
src ::/0 dst ::/0
socket out priority 0 ptype main
src ::/0 dst ::/0
socket in priority 0 ptype main
src ::/0 dst ::/0
socket out priority 0 ptype main
src 10.10.10.0/24 dst 192.168.200.0/24
dir in priority 373888 ptype main
tmpl src 111.222.333.444 dst 222.333.444.555
proto esp reqid 1 mode tunnel
src 10.10.10.0/24 dst 192.168.200.0/24
dir fwd priority 373888 ptype main
tmpl src 111.222.333.444 dst 222.333.444.555
proto esp reqid 1 mode tunnel
src 192.168.200.0/24 dst 10.10.10.0/24
dir out priority 373888 ptype main
tmpl src 222.333.444.555 dst 111.222.333.444
proto esp spi 0xd6b8faff reqid 1 mode tunnel
The last three entries I added myself, 192.168.200.0/24 is our internal LAN. I hoped that this would be the way to tell strongswan that packets from our internal LAN to 10.10.10.0 should get the ipsec policy, but it does not work.
Following iptables rules exist:
-A OUTPUT -m policy --dir out --pol ipsec -j NFLOG --nflog-group 5
-A FORWARD -m addrtype ! --dst-type LOCAL -m policy --dir in --pol ipsec -j NFLOG --nflog-group 5
-A FORWARD -s 10.10.10.0/24 -d 192.168.100.0/24 -i ppp1 -m policy --dir in --pol ipsec --reqid 1 --proto esp -j ACCEPT
-A FORWARD -s 192.168.100.0/24 -d 10.10.10.0/24 -o ppp1 -m policy --dir out --pol ipsec --reqid 1 --proto esp -j ACCEPT
-A INPUT -m addrtype --dst-type LOCAL -m policy --dir in --pol ipsec -j NFLOG --nflog-group 5
and in the nat table:
-A POSTROUTING -m policy --dir out --pol ipsec -j ACCEPT
-A POSTROUTING -s 192.168.200.0/24 -o ppp1 -j MASQUERADE
So, am I missing something out?
History
#1 Updated by Noel Kuntze about 1 month ago
- Category set to configuration
- Status changed from New to Feedback
- Assignee set to Noel Kuntze
Hi,
Traffic received by an IPsec peer is always checked against the negotiated IPsec policies, so even if you change them locally, they will not match on the other peer.
You need to negotiate the required traffic selectors either using one CHILD_SA or several CHILD_SAs (IKEv1 by design can not handle multiple subnets per side and proprietary firewall/VPN gateways often can't handle that either). The FAQ expands on that and the interoperability articles mention which implementations can not handle that, even with IKEv2.
Take a look at the UsableExamples page that show you how to configure multiple CHILD_SAs.
Your config looks really old, you should update that (e.g. remove pfs=yes, which doesn't exist in strongSwan).
#2 Updated by Konstantin Kletschke about 1 month ago
Dear wiki, dear Noel,
I am a colleauge of the initial threadstarter Thomas and trying to figure this out with him.
What me bothers is... honestly I do not understand your friendly answer until know, I admit.
We do not have a problem with the right/left subnet assigning. We have a given config from our partner and adapted to it, as said on the firewall itself we can ping members on the rightsubnet fine, ssh works also.
Now we need to adapt this leftsubnet to our working net (in fact, we have two in mind finally) which should be able to access IPs in the rightsubnet. And what me bothers I have the feeling it is not missing very much. And I have difficulties to understand the scenario due to the lack of an (virtual) tunnel endpoint interface. If it existed (like in openvpn/wireguard) I would think about simple routing...
Our working subnet 192.168.200.0/18 is attached to eth1 and fed via DHCP.
Note: The initial post showed this as 192.168.200.0/24, this is a Typo, we are running this 192.168.200.0/18.
The leftsubnet of our IPSEC/VPN is 192.168.100.7/24 and eth2 has manually 192.168.100.1 assigned. eth2 is otherwise unconnected it is only physically present as a NIC with no connection to carry the 192.168.100.1. All applies to the fw/gateway computer, pinging rightsubnet works here.
Now I am searching a way to route/guide traffic from our work-subnet 192.168.200.0/18 into the tunnel to access rightsubnet from there also.
Is this possible? In my feeling there is not missing much.
When we assign a 192.168.100.x IP to a DHCP client on 192.168.200.0/18 manually additionally, THEN pinging the rightsubnet from there works too!
What tiny bit I am missing to be done to the firewall/gateway? Is this done by "traffic selectors using CHILD_SAs"?
I carefully read your answer but I thought the traffic selector CILD_SA stuff is given from the given IPSEC config from the customer's setup (which is a fortigate in our case), i.e. those need to be confiugred there 1:1 also.
Additionally we intend to access the rightsubnet from our 192.168.200.0/18 AND an additional 10.20.0.x (the latter was not touched yet).
Or is the only way to...hm... incorporate those nets as leftsubnets with the customer into the config only? But this would offer our complete internal network infrstructure to those also with no possibilities to route of firewall anything.
Kind Regards
Konstantin
#3 Updated by Tobias Brunner about 1 month ago
You'll obviously have to NAT traffic from 192.168.200.0/18 to 10.10.10.0/24 to an IP address in 192.168.100.0/24 (and do so before the MASQUERADE rule) as traffic otherwise won't match the negotiated traffic selectors (to avoid the NAT, negotiate 192.168.200.0/18 as local traffic selector).