Using ipsec tunnel from "foreign" subnet
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?
#1 Updated by Noel Kuntze 4 months ago
- Category set to configuration
- Status changed from New to Feedback
- Assignee set to Noel Kuntze
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 4 months 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.
#3 Updated by Tobias Brunner 4 months 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).