Navigation

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

    Client connected via OpenVPN, not routing through IPSec

    OpenVPN
    2
    4
    16
    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.
    • M
      Masin Al-Dujaili last edited by

      Hello!

      I have 2 sites connected via IPSec tunnel (and soon a third site). One site, let's call it A, provides VPN service using OpenVPN. When pinging an address at site B, I get the following message:

      36 bytes from 10.3.20.1: Time to live exceeded
      Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
       4  5  00 5400 aa2d   0 0000  01  01 0000 10.3.101.2  10.0.20.23 
      
      Request timeout for icmp_seq 0
      

      Capturing the traffic on site A's OpenVPN server interface:

      10:01:12.219901 IP 10.3.20.1 > 10.3.101.2: ICMP time exceeded in-transit, length 72
      10:01:14.377123 IP 10.3.101.1 > 10.3.101.2: ICMP time exceeded in-transit, length 36
      10:01:14.399681 IP 10.3.101.1 > 10.3.101.2: ICMP time exceeded in-transit, length 36
      10:01:14.412161 IP 10.3.101.1 > 10.3.101.2: ICMP time exceeded in-transit, length 36
      10:01:14.435558 IP 10.3.20.1 > 10.3.101.2: ICMP time exceeded in-transit, length 36
      

      When ssh'in into site A's gateway I can ping the address in site A's subnet. I can log into site B's gateway and ping addresses in site A's subnets. So, I guess the IPSec tunnel might be configured correctly.

      But!:

      There are several subnets on each site (seven ATM). I configured a phase 2 for each of the subnets. The config looks like this:
      Local Network: <specific> subnet
      NAT/BINAT: none
      Remote Network: <corresponding subnet on other site>

      As IPSec is somewhat new to me, I cannot rule out that I botched that part. :-)

      Can someone point me into the right direction?

      Bests,
      Masin Al-Dujaili

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

        You also need a phase 2 for the OpenVPN tunnel network on both IPSeec routers for each network you want to access on site B.

        M 1 Reply Last reply Reply Quote 1
        • M
          Masin Al-Dujaili @viragomann last edited by

          @viragomann Oh, thanks. Sometimes it's so 'easy'. 😂

          Now, at least, the ping reaches the ovpns2 interface on site A in a form that's more as I expect. But it still doesn't get routed through enc0. I checked if I needed additional static routes or gateways but there's nothing to consider regarding the OpenVPN subnet as far as I see (which might not be far enough).

          So, site A receives ICMP echo requests at ovpns2. But I cannot see where they go next or if they go anywhere at this point.

          I should add that the firewall allows all traffic on all interfaces participating, namely IPSec and OpenVPN at the moment.

          M 1 Reply Last reply Reply Quote 0
          • M
            Masin Al-Dujaili @Masin Al-Dujaili last edited by

            The solution to my problem was to ditch policy-based IPSec and switch to route-based IPSec. This reduces the number of phase 2 entries by a lot but requires more static routes. IMHO it's better this way because there's no intransparent mix of different ways of routing packages between their destinations. Now everything is just in the routing table.

            1 Reply Last reply Reply Quote 0
            • First post
              Last post

            Products

            • Platform Overview
            • TNSR
            • pfSense
            • Appliances

            Services

            • Training
            • Professional Services

            Support

            • Subscription Plans
            • Contact Support
            • Product Lifecycle
            • Documentation

            News

            • Media Coverage
            • Press
            • Events

            Resources

            • Blog
            • FAQ
            • Find a Partner
            • Resource Library
            • Security Information

            Company

            • About Us
            • Careers
            • Partners
            • Contact Us
            • Legal
            Our Mission

            We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

            Subscribe to our Newsletter

            Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

            © 2021 Rubicon Communications, LLC | Privacy Policy