[SOLVED] IPsec Phase 2 for OpenVPN tunnel networks?
-
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,
-
@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.
-
@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,
-
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.
-
@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 262144RUT-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/24In 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,
-
@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.
-
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 -
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.6Tracing 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.6The 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 hops1 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.6Does this information lead to anything or should I continue to grab a trace?
-
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 40RUTOS, 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 40This analyze correct?
-
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.
-
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.
-
@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. -
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 40Thank you for bearing with me through this. Hopefully some one else will find and benefit from this conversation.
-
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.
