Project

General

Profile

Issue #3606

Using ipsec tunnel from "foreign" subnet

Added by Thomas Blum about 1 month ago. Updated about 1 month ago.

Status:
Feedback
Priority:
Normal
Assignee:
Category:
configuration
Affected version:
5.7.2
Resolution:

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).

Also available in: Atom PDF