Learn about the Benefits of Multi-Factor Authentication (MFA) . Turn your MFA on now!
Information: Three minute survey on Exploring more ways to contact Sophos Technical Supportt. If you can spare the time, we would love your feedback!
We'd love to hear about it! Click here to go to the product suggestion community
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 184.108.40.206, 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 220.127.116.11, 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?
Both Hub and Spoke Site-to-Site VPNs and How to allow remote access users to reach another site via a Site-to-Site Tunnel apply the same ideas. Does that give you the result you were looking for?
Cheers - Bob
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:
No need for Client@Home to create a second VPN tunnel.
In reply to BAlfson:
Hub and Spoke Site-to-Site VPNs
I saw that one, it didn't quite help me, as I don't have site 2 site between each site, rather only over first two, home and work, and I am connecting the thin-client from home via IPSEC/IKE to the remote gateway (public IP). My s2s seems fine, as I can well control what I access from home to work and vice versa.
Would I need to allow the access to internet in the remote networks in the S2S setup?
How to allow remote access users to reach another site via a Site-to-Site Tunnel
This looks very much same to me to the above example. Entering each others networks in the S2S settings, this time though using the RemoteSSL Pool.
In reply to DouglasFoster:
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.
In reply to Kosta88:
A diagram would help - I just can't "see" what you're wanting to accomplish.
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 18.104.22.168
- when my TC at home connects to the Datacenter, it's "showing" it 22.214.171.124
What I want: TC at home should be visible to the Datacenter as it were coming from 126.96.36.199 (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...
NOTE (next day): In both cases, you will need an SNAT or a masq rule at work that changes the packet source from 188.8.131.52 to 184.108.40.206.
Let us know if you try one or both and which you decided to go with.
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:
Two Policy Routes:
- to 220.127.116.11 via 10.10.10.254
- to networks in the Datacenter via 10.10.10.254
S2S IPsec Remote Gateways:
- 18.104.22.168 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.
Ah, yes - I'll need to add that to my post above - thanks!
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.
I don't understand the question about the VPN definition - does that pertain to the screenshot of the Multipath-Rules above?
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 22.214.171.124), but I can't connect from 192.168.1.254 to 126.96.36.199).
The Site-to-Site tunnel between 192.168.1.254 and 10.10.10.254 still remains over LTE, and should remain over LTE.