[SOLVED] IPsec Phase 2 for OpenVPN tunnel networks?

iorx

@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

@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

@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

@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

@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

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

@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

@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

@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

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.