BOVPN to a customer - Route our own remote IPSEC VPN Users

DSI_SupDSI_Sup
in Firebox - VPN Branch Office

We've tried looking but havent found an exact answer, we have a BOVPN between us and a customer. The Tunnel is up and works fine on our internal network, we can connect to hosts at their site.

We have also created a tunnel between us and them for our remote VPN user range, just for example IPSEC users are on 192.1.2.0/24, our internal network is 192.1.1.0/24

We want the remote ISPEC VPN users to be able to reach the customer network on say 10.1.0.0/16

Do we need to add a route or something so the IPSEC users know about the 10.1.0.0/16 network? if so where?

Currently they have to connect to a local jump box and then connect out to the 10.1.0.0 network

Thanks

Comments

  • Bruce_BriggsBruce_Briggs

    Do you have "Force All Traffic Through Tunnel" selected in your MUVPN setup?
    If not, you can add 10.1.0.0/16 to the Allowed Resources list.

  • Bruce_BriggsBruce_Briggs

    If you change the MUVPN setup, you need to Generate new MUVPN profiles and send the new profile to your MUVPN users to import into their MUVPN app.

  • DSI_SupDSI_Sup

    Thanks Bruce, easy once you know where to look. It did not do the trick though. I can see the network range as an allowed resource on the MUVPN client now, but can't reach the network still.

    I'll also check to see if the customer can see us trying to connect to hosts. Anything else we could be missing?

  • Bruce_BriggsBruce_Briggs
    edited March 2022

    What is an example IP addr at the remote site that a MUVPN user is trying to access?
    What is a sample native IP addr of a MUVPN client PC? MUVPN user's PC on such as user - 10.0.1.23 & dest = 10.1.1.xxx ??

    For debugging, you can turn on Logging on the MUVPN policy to see packets allowed by it in Traffic Monitor.
    Do so, and have MUVPN user try to access the remote site.
    If you see this access in Traffic Monitor, then the issue is that the reply packets at the other end are not making it back. Most likely a routing issue.

    Have you added 192.1.2.0/24 to the BOVPN setup at each end?
    If not you must for packets from 192.1.2.x to get routed to the remote site.

    Also 192.1.1.0/24 & 192.1.2.0/24 are not private subnets. Are these the real internal subnets in use?

  • DSI_SupDSI_Sup

    Native MUVPN client is 192.168.116.12 and trying to contact remotely at a customer 10.120.2.138

    We have added a tunnel for 192.168.116.0/24 at each end user and can see the tunnel come up occasionally.

    We'll try debugging.

    No they were just random examples. Actual ranges now as above and out internal is 192.168.254.0

  • watchguardianwatchguardian
    Hi,

    I would recommend you to build the setup differently.
    Put the virtual mobile vpn pool in your customer's site-to-site ipsec tunnel. --> Just one site-to-site tunnel and all necessary routes included on your and customer site (mobile vpn pool)

    Is the site-to-site tunnel policy based or routed based?

    Is the IPsec Mobile VPN configurated for full or splitt tunnel?
  • DSI_SupDSI_Sup

    Hi, been a crazy few dates and just seen this. We have actually put the mobile VPN pool in the tunnel between us and the customer and the tunnel looks to come up occasionally but they see no traffic.

    So I think it is a routing issue as the tunnel is route based. So maybe we are missing a route...

    We have configured split tunnel on the MVPN.

    Thanks!

  • watchguardianwatchguardian
    Hi,

    ok. Is the route to the vpn pool on customer site configurated for the site-to-site tunnel?
    Is the the remote subnet included in the mobile vpn configuration?
Sign In to comment.