This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

VPN over VPN, possibly with SNAT

Hello,

I want to do an IPSEC/IKE Client-Connection to a remote network, but over an existing Site-2-Site tunnel. And I only want to route this Client via Work-Network, not everything at home. For the remote network, it should appear as if the packets are coming from the work-network, although the client is in the home network.

It's like this:

Client@Home / Home-Network (192.168.1.0, Sophos 192.168.1.254) -> S2S -> Work-Network (10.10.10.0, Sophos 10.10.10.254) -> Remote-Network (public IP 193.10.1.1, non-manageable nor managed by me)

Client@Home is doing IPSEC/IKE VPN to the public IP of the Remote-Network.

So, what I'm doing:

I have a standard static route in place, saying: For connections to 193.10.1.1, use Gateway at work (10.10.10.254).

Now I'm thinking, what do I have to put into S2S networks, both local and remote. If anything at this point. All I want to is to establish a VPN-connection, not access any networks inside the tunnel - except the ones that are already set up, like the Home-Network and Work-Network, which are already in there obviously.

I also created the back-route for the Client, I set up a static route for Home-Networks to be the 192.168.1.254, though I don't think that's needed. At this point I am trying to connect the VPN from the Client with the Remote-Network over the Sophos at work. No-go.

I tried packet capture via CLI, monitoring the internal interface of the home Sophos, I see the packets, going from the client to the remote-network public IP, and then just the 2nd packet is already: publicIP sophos@home > client@homeIP: ICMP host "remote-publicIP" unreachable.

If I remove the routing via sophos@work, then VPN connects.

Please, am I missing something obvious?

Thank you.



This thread was automatically locked due to age.
Parents
  • You said:

    • Client@Home is doing IPSEC/IKE VPN to the public IP of the Remote-Network.

    I don't see how this will work.   If it can make a tunnel-within-tunnel route at all, you are likely to have problems with MTU, latency, and debugging.

    I think what you want:

    • Client@Home is connected to Work-Network using a Client@Home VPN address.
    • Work-to-Remote tunnel allows certain work addresses to connect to certain remote addresses.
    • SNAT is used to map the Client@Home VPN Address to a (reserved) Work Address so that the Work-To-Remote tunnel will accept the packet.
    • If Client@Home is using Remote Access VPN, the SNAT rule can reference the user or group object instead of a fixed IP object, depending on your needs.

    No need for Client@Home to create a second VPN tunnel.

     

     

  • I think what you want:

    • Client@Home is connected to Work-Network using a Client@Home VPN address.
    • Work-to-Remote tunnel allows certain work addresses to connect to certain remote addresses.
    • SNAT is used to map the Client@Home VPN Address to a (reserved) Work Address so that the Work-To-Remote tunnel will accept the packet.
    • If Client@Home is using Remote Access VPN, the SNAT rule can reference the user or group object instead of a fixed IP object, depending on your needs.

    No need for Client@Home to create a second VPN tunnel.

    The scope of what I can configure on the Client@Home is very limited.

    Client@Home obtains it's local IP from the DHCP, and it's possible to set it static. But, I can't configure where VPN connects to.

    Client@Home isn't connected to the Work-Network, it's connected to the Home@Network, as it's at home...

    I also cannot force the Client@Home to not use the IPSEC remote connection, as it is basically programmed, and limited to me clicking the Icon on the desktop which calls up the VPN connection, and then automatically starts a browser which opens the remote terminal server. I can't work around that.

    If the client is at work, it also has to build the same VPN tunnel, it won't work without the tunnel. It also builds a tunnel straight via internet.

     

    And why I want to re-route it is simply because I want to have it appear to the remote server as if the connection is coming from work, if at all possible.

  • A diagram would help - I just can't "see" what you're wanting to accomplish.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  •  

    Sorry for delay, real world work.

    I hope this helps.

    As you can notice:

    - all TCs currently connect directly to the Datacenter, building a IPSEC/IKE tunnel by themselves

    - when TCs at work connect to the Datacenter, they have an external IP 88.88.88.88

    - when my TC at home connects to the Datacenter, it's "showing" it 77.77.77.77

    What I want: TC at home should be visible to the Datacenter as it were coming from 88.88.88.88 (WAN IP at work)

     

    Is it achievable to make my TC at home connect it's IPSEC/IKE VPN through the Site2Site tunnel between Sophos at home and Sophos at work? (in essence, that is a tunnel in a tunnel)

  • I think there are two ways to accomplish this.  I think both are fairly simple...

    1. Add 99.99.99.99 to 'Local Networks' at work and to 'Remote Networks' at home.  If you're not using 'Automatic firewall rules', you will need to add it to your manual rules.
    2. In your home, make a Static Gateway Route: 99.99.99.99 via 88.88.88.88.  At work, make a firewall rule: '77.77.77.77 -> Any -> 99.99.99.99 : Allow'.

    NOTE (next day): In both cases, you will need an SNAT or a masq rule at work that changes the packet source from 77.77.77.77 to 88.88.88.88.

    Let us know if you try one or both and which you decided to go with.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • I don't believe it, but I think it works. Finally - it was merely a small thing, actually what I wrote above. I didn't consider that the TC at home must first connect the VPN, and it's doing that to an external IP (over the S2S tunnel). So I had to allow that through the tunnel too. I was only allowing private networks, but didn't think about the public one.

    Anyway, the following setup:

    Sophos Home:

    Two Policy Routes:

    - to 99.99.99.99 via 10.10.10.254

    - to networks in the Datacenter via 10.10.10.254

    S2S IPsec Remote Gateways:

    - 99.99.99.99 and Datacenter networks

    Sophos at Work:

    SNAT for TC at home, Any/Any, translation to "Internal (Address)" (=10.10.10.254)

    S2S IPsec Local Networks: same as above.

     

    Only thing, I would like to make sure that it's working.

    How can I actually do that, without any information from Datacenter? (I don't even believe they can go as far as invest that on request)

  • Thanks. I think we posted at the same time, rofl ;-)

    The solution I wrote too is basically your 1st solution, I had to add the public IP, which I didn't at first consider.

    However, re-reading your suggestions, I think these two complement each other, because without adding of the appropriate networks in both Local Networks and Remote Networks, nothing was working.

    Also, it doesn't seem to work without SNAT at all.

Reply
  • Thanks. I think we posted at the same time, rofl ;-)

    The solution I wrote too is basically your 1st solution, I had to add the public IP, which I didn't at first consider.

    However, re-reading your suggestions, I think these two complement each other, because without adding of the appropriate networks in both Local Networks and Remote Networks, nothing was working.

    Also, it doesn't seem to work without SNAT at all.

Children
  • Ah, yes - I'll need to add that to my post above - thanks!

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Hello,

    I want to change something, and the change doesn't work, so I think I best revisit this here.

    Sophos router at work has two WAN connections: LTE and DSL.

    Right now, I am using a single WAN connection (LTE) for everything - both connection between Sophos@Home and Sophos@Work (Site-to-Site) AND between Sophos@Work and Datacenter.

    However, I would like to switch the connection between Sophos@Work and Datacenter to another WAN connection (DSL).

    Currently I have an Interface Uplink with both LTE and WAN, and using Multipath Rules to regulate it. I have two rules in Multipath Rules:

    1. "RemoteNetwork (Datacenter) via WAN (by Interface)" (Any -> Any -> RemoteNetworks -> External WAN LTE)

    2. "LTE Balancing (by Interface)" (Any -> Any -> Any -> External WAN LTE)

     

    What I'd like to do is change the Rule #1 to "External WAN DSL".

    When I do that, connection of the TC with the Datacenter fails.

     

    I am failing to understand why.

  • Have you changed the VPN definition at the Data Center to use the IP of "External WAN DSL (Address)" instead of the LTE interface?

    Please show a picture of the Edit of Multipath Rule 1 above.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • I don't understand the question about the VPN definition - does that pertain to the screenshot of the Multipath-Rules above?

     

    Multipath:

    The black marked destination is a group of related networks in the data center. It contains 3 entries, one public IP of the VPN and two private networks in the data center.

    If I switch the first Multipath-Rule to "External (WAN) DSL", then I can still connect from work to data center (from 10.10.10.254 to 99.99.99.99), but I can't connect from 192.168.1.254 to 99.99.99.99).

    The Site-to-Site tunnel between 192.168.1.254 and 10.10.10.254 still remains over LTE, and should remain over LTE.