Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    [SOLVED] IPsec Phase 2 for OpenVPN tunnel networks?

    Scheduled Pinned Locked Moved IPsec
    14 Posts 2 Posters 963 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • iorxI
      iorx @viragomann
      last edited by

      @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,

      1 Reply Last reply Reply Quote 0
      • V
        viragomann
        last edited by

        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.

        iorxI 1 Reply Last reply Reply Quote 0
        • iorxI
          iorx @viragomann
          last edited by 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,

          V 1 Reply Last reply Reply Quote 0
          • V
            viragomann @iorx
            last edited by

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

            iorxI 1 Reply Last reply Reply Quote 0
            • iorxI
              iorx @viragomann
              last edited by

              @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
              
              
              iorxI 1 Reply Last reply Reply Quote 0
              • iorxI
                iorx @iorx
                last edited by

                @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?

                iorxI 1 Reply Last reply Reply Quote 0
                • iorxI
                  iorx @iorx
                  last edited by

                  @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?

                  1 Reply Last reply Reply Quote 0
                  • V
                    viragomann
                    last edited by 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.

                    iorxI 1 Reply Last reply Reply Quote 0
                    • iorxI
                      iorx @viragomann
                      last edited by

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

                      V 1 Reply Last reply Reply Quote 0
                      • V
                        viragomann @iorx
                        last edited by

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

                        iorxI 1 Reply Last reply Reply Quote 0
                        • iorxI
                          iorx @viragomann
                          last edited by

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

                          1 Reply Last reply Reply Quote 0
                          • V
                            viragomann
                            last edited by

                            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.

                            1 Reply Last reply Reply Quote 0
                            • First post
                              Last post
                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.