[SOLVED] IPsec Phase 2 for OpenVPN tunnel networks?

iorx · May 15, 2020, 4:12 AM

Hi ladies and germs!

IPsec Phase 2 for OpenVPN tunnel networks?

I've not been able to get an answer for this one and needs some confirmation. The logic on basic routing tells me it should be one, but here goes:

So in a multi site-to-site with OpenVPN and IPsec

OpenVPN site [10.10.0.1/24] <-> OpenVPN-tunnel [10.0.8.0/24] <-> pfSense[192.168.1.1/24] <-> IPsec [192.168.10.1/24]

So, in the creation of the IPsec, a P2 for OpenVPN site [10.10.0.1/24] is obvious.
To get things flowing then a P2 for OpenVPN-tunnel [10.0.8.0/24] should also be created?

Brgs,

viragomann · May 14, 2020, 6:06 AM

@iorx said in IPsec Phase 2 for OpenVPN tunnel networks?:

To get things flowing then a P2 for OpenVPN-tunnel [10.0.8.0/24] should also be created?

No. That is only reasonable for OpenVPN access servers, so that the VPN clients who get IPs out of the tunnel subnet are able to access the network behind the IPSec.

iorx · May 14, 2020, 6:06 AM

@viragomann said in IPsec Phase 2 for OpenVPN tunnel networks?:

@iorx said in IPsec Phase 2 for OpenVPN tunnel networks?:

To get things flowing then a P2 for OpenVPN-tunnel [10.0.8.0/24] should also be created?

No. That is only reasonable for OpenVPN access servers, so that the VPN clients who get IPs out of the tunnel subnet are able to access the network behind the IPSec.

Ok, so I've tried this out now.

This contradict my experience with this setup.

Without the tunnel network defined as P2 the client site-to-site hosts can't reach the IPsec-network. But, the other way around is reachable. That is, IPsec hosts can reach clients in the site-to-site network.

Something up, done wrong, with the way I've configured this?

Brgs,

viragomann · May 14, 2020, 9:58 AM

Maybe you have a client connection, while talking about a site-to-site?
Or do you NAT into the OpenVPN tunnel?

In a true site-to-site you have two or more networks on two sites, which you connect via VPN. The VPN tunnel between the two sites is a transit network, which means the traffic between the two location flows over it, but it's not addressed by any IP packet. The traffic is controlled by routes.

Since no client has an IP out of the tunnel subnet, there is no need to add a P2 for it. You only have to add the networks behind the VPN.
If your VPN client gets an IP out of the tunnel you need to add a P2 for the tunnel network to get a connection to the network behind the IPSec.

So in your case, you should only have to add a P2 for 10.10.0.1/24, so this network is routed to pfSense and there this network is set in "IPv4 Remote networks" option in OpenVPN site-to-site settings.

iorx · May 14, 2020, 2:33 PM

@viragomann
This gets interesting. As you describe it is exactly how I was expecting it to work and initially did the setup.

Pretty sure this is a site-to-site. OpenVPN is site-to-site with shared secret. Clients sides are both Teltonika (RUT-OS, OpenWrt based) and pfSense.
As in my figure, the server is a pfSense.

NAT isn't enabled what I know of. If it was I should have problem directly connecting to the hosts on the OpenVPN client LAN from 10.200.140. server LAN?

To make things very clear I attach the configs from clients and server here.

My IP-ranges before were made up, so here are the real ranges and IP, so it matches the config-files down below:

IPsec LAN: 10.250.0.0/16
Server LAN: 10.200.140.0/24
Tunnel network: 10.0.208.0/24 (201,202,...,208,...,211)
Client LAN: 10.201.8.0/24 (1,2,3,...,8,...,11)

[x]=cleaned up identifiable information

pfSense OpenVPN server config for 10.201.8.0/24 (picked up from /var/etc/openvpn/server16.conf)

dev ovpns16
verb 1
dev-type tun
dev-node /dev/tun16
writepid /var/run/openvpn_server16.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp4
cipher BF-CBC
auth SHA1
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
multihome
ifconfig 10.0.208.1 10.0.208.2
lport 1208
management /var/etc/openvpn/server16.sock unix
route 10.201.8.0 255.255.255.0
secret /var/etc/openvpn/server16.secret
fast-io
sndbuf 262144
rcvbuf 262144

RUT-OS OpenVPN Client (/tmp/etc/openvpn-636C69656E745F4851.conf)

nobind
persist-key
cipher BF-CBC
dev tun_c_HQ
ifconfig 10.0.208.2 10.0.208.1
port 1208
proto udp
remote exvpn.[company].se
resolv-retry infinite
route 10.200.140.0 255.255.255.0
secret /lib/uci/upload/cbid.openvpn.636C69656E745F4851.secret
verb 5
route 10.250.0.0 255.255.0.0

(yes I know BF-CBC... some clients are rather weak hardware so to get some kind speed I did this not so responsible choice on some of them)

IPsec pfSense (/usr/local/etc/ipsec.conf)

config setup
        uniqueids = yes

conn bypasslan
        leftsubnet = 10.200.140.0/24
        rightsubnet = 10.200.140.0/24
        authby = never
        type = passthrough
        auto = route

conn con4000
        fragmentation = yes
        keyexchange = ikev2
        reauth = yes
        forceencaps = no
        mobike = no

        rekey = yes
        installpolicy = yes
        type = tunnel
        dpdaction = restart
        dpddelay = 10s
        dpdtimeout = 60s
        auto = route
        left = [public pfsense IP]
        right = [public dest IP]
        leftid = [public pfsense IP]
        ikelifetime = 10800s
        lifetime = 3600s
        ike = aes256-sha256-modp1024!
        esp = aes256-sha256,aes256-sha256,aes256-sha256,aes256-sha256,aes256-sha256!
        leftauth = psk
        rightauth = psk
        rightid = [public dest IP]
        rightsubnet = 10.250.0.0/16
        leftsubnet = 10.200.140.0/24,10.0.0.0/16,10.200.0.0/16,10.201.0.0/16,10.66.74.0/24

In this config if I don't have 10.0.0.0/16 as P2 on both sides I don't get routing to work from the OpenVPN client networks 10.201. to 10.250.
The other way around works without the P2.

Feels like I'm missing something here or done something horribly wrong

Brgs,

viragomann · May 14, 2020, 2:33 PM

@iorx said in IPsec Phase 2 for OpenVPN tunnel networks?:

NAT isn't enabled what I know of. If it was I should have problem directly connecting to the hosts on the OpenVPN client LAN from 10.200.140. server LAN?

That's not true. NAT doesn't influence that at all.

@iorx said in IPsec Phase 2 for OpenVPN tunnel networks?:

In this config if I don't have 10.0.0.0/16 as P2 on both sides I don't get routing to work from the OpenVPN client networks 10.201. to 10.250.
The other way around works without the P2.

Again, the only one idea I get in respect of this is that the client does NAT (masquerading) on packets going into the VPN tunnel.

Just take a packet capture on the OpenVPN interface, while you try a connection from the client site to 10.250.0.0/16 and look which source IP the packets have.

iorx · May 14, 2020, 3:23 PM

@viragomann

I'll capture some traffic later today.

This is me not knowing stuff, and it's not the forums, or your, tasks to teach me. So should I just read up on thing and come back?

I got so confused on the NAT thing here (this is a OpenVPN subject though). Client network hosts are registered and reached at the LAN IP they actually have, not on the (I presume if NAT is enabled) a translated address.

I must have misunderstood how this is done in the OpenVPN or system internals.

So until I come back with result on the capture. Checked the iptable rules on RUTOS, but this doesn't tell me much. An unqualified guess is that traffic from the zone hotspot is translated if going into the tun interface.
Could it be that RUTOS iptables does some translation that I can't find/see?

This was from just googling for list NAT tables on linux. Ran it and the result:

root@ae6:/tmp/etc# iptables -t nat -L -n -v | grep 'tun'
55376 6554K zone_vpn_prerouting  all  --  tun_+  *       0.0.0.0/0            0.0.0.0/0     
    0     0 zone_hotspot_prerouting  all  --  tun0   *       0.0.0.0/0            0.0.0.0/0 
    0     0 zone_hotspot_prerouting  all  --  tun1   *       0.0.0.0/0            0.0.0.0/0 
    0     0 zone_hotspot_prerouting  all  --  tun2   *       0.0.0.0/0            0.0.0.0/0 
    0     0 zone_hotspot_prerouting  all  --  tun3   *       0.0.0.0/0            0.0.0.0/0 
40768 2859K zone_vpn_postrouting  all  --  *      tun_+   0.0.0.0/0            0.0.0.0/0    
    0     0 zone_hotspot_postrouting  all  --  *      tun0    0.0.0.0/0            0.0.0.0/0
    0     0 zone_hotspot_postrouting  all  --  *      tun1    0.0.0.0/0            0.0.0.0/0
    0     0 zone_hotspot_postrouting  all  --  *      tun2    0.0.0.0/0            0.0.0.0/0
    0     0 zone_hotspot_postrouting  all  --  *      tun3    0.0.0.0/0            0.0.0.0/0

iorx · May 14, 2020, 7:41 PM

@iorx

Haven't recorded traffic just researching some things here. Trying to understand.

I'm on a host, Windows, with IP 10.200.160.124
I trace an IP to the other side of the IPsec.
The tunnel address 10.0.160.1 is present in this trace and is the last jump before reaching IPsec host 10.250.1.6

Tracing route to [10.250.1.6]
over a maximum of 30 hops:
  1     5 ms     2 ms     2 ms  10.200.160.1
  2     3 ms     4 ms     6 ms  10.0.160.1
  3    29 ms    26 ms    25 ms  10.250.1.6

The OpenVPN Client here is site-to-site on pfSense.

It looks the same from a Windows host, 10.201.15.171, behind RUTOS,
Tracing route to 10.250.1.6 over a maximum of 30 hops

1     5 ms     5 ms     6 ms  10.201.15.1
2    30 ms    30 ms    30 ms  10.0.215.1
3    63 ms    45 ms    55 ms  10.250.1.6

Does this information lead to anything or should I continue to grab a trace?

iorx · May 14, 2020, 7:57 PM

@iorx

Trace done on the IPsec interface.

OK, pfSense as client looks like this LAN to IPsec addresses.

21:55:25.925269 (authentic,confidential): SPI 0xb0dce3b6: IP 10.200.160.124 > 10.250.1.7: ICMP echo request, id 1, seq 362, length 40
21:55:25.946567 (authentic,confidential): SPI 0xc08c59e7: IP 10.250.1.7 > 10.200.160.124: ICMP echo reply, id 1, seq 362, length 40
21:55:26.938072 (authentic,confidential): SPI 0xb0dce3b6: IP 10.200.160.124 > 10.250.1.7: ICMP echo request, id 1, seq 363, length 40
21:55:26.959204 (authentic,confidential): SPI 0xc08c59e7: IP 10.250.1.7 > 10.200.160.124: ICMP echo reply, id 1, seq 363, length 40

RUTOS, here I suspect NAT because I only see the tunnel address not any LAN address.

21:51:01.576154 (authentic,confidential): SPI 0xc08c59e7: IP 10.250.1.7 > 10.0.215.2: ICMP echo reply, id 1, seq 629, length 40
21:51:02.581453 (authentic,confidential): SPI 0xb0dce3b6: IP 10.0.215.2 > 10.250.1.7: ICMP echo request, id 1, seq 630, length 40
21:51:02.602936 (authentic,confidential): SPI 0xc08c59e7: IP 10.250.1.7 > 10.0.215.2: ICMP echo reply, id 1, seq 630, length 40

This analyze correct?

viragomann · May 14, 2020, 8:21 PM

Seems you have changed the OpenVPN tunnel network. That's why I couldn't interpret the trace from the clients network.

@iorx said in IPsec Phase 2 for OpenVPN tunnel networks?:

RUTOS, here I suspect NAT because I only see the tunnel address not any LAN address.

So yes, that's what I'm talking about all the time.

This is the default setting when you set up an upstream VPN connection to a provider for accessing the internet, but it's not reasonable for a site-to-site.

However, I'm not familiar with the OpenWRT and iptables.

iorx · May 14, 2020, 8:40 PM

@viragomann

Thanks allot for your patience with me. My underwhelming knowledge on the subject stole your time guiding me on this subject. Sorry about that.
But, I've learned something and got the insight how little I understand of iptables, routing and OpenVPN in combination.
Yet, I've been reading some info on iptables, zones and OpenWrt... really confusing. But I prevail, this can't be just me wanting a OpenVPN client connected without NAT with full routing.

I'll return here when I've figured this out.

Thanks again.

viragomann · May 14, 2020, 8:50 PM

@iorx
As far as I know, masquerading must be explicitly stated when adding an iptables rule. So it should not be set by default.
However, maybe that's not valid for OpenWRT.

iorx · May 15, 2020, 4:11 AM

@viragomann

SOLUTION: Remove NAT/MASQUERADE in the OpenVPN-zone (OpenWrt in my case)

This is awkward, the blizz of not knowing how stuff work is on display in this thread (from my side).

Here goes.
You simply need to remove masquerading from the OpenVPN-zone in OpenWRT/RUTOS. That's a one click operation!

Now straight routing and no NAT:

05:35:47.854280 (authentic,confidential): SPI 0x69293840: IP 10.201.15.171 > 10.250.1.7: ICMP echo request, id 1, seq 163, length 40
05:35:47.875638 (authentic,confidential): SPI 0xc1cdd81e: IP 10.250.1.7 > 10.201.15.171: ICMP echo reply, id 1, seq 163, length 40

Thank you for bearing with me through this. Hopefully some one else will find and benefit from this conversation.

viragomann · May 15, 2020, 9:51 AM

Great that it is working now as it should be. And my respect that you stayed on this till you solved it and posted the solution here.