Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 11 replies
  • Subscribers 1 subscriber
  • Views 19653 views
  • Users 0 members are here
Options
Suggested
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

How to route SSL VPN clients to next hop network

whitetr6
I'm not sure what the right approach to this would be.

I have a Sophos 120, running 9.2x. I have configured a SSL VPN that allows the clients that log in to get to all of the resources in the same local network as the UTM itself. Let's call that 192.168.1.x

I have a second network, 192.168.2.x and there is a separate router (not the UTM) to allow traffic between the two networks.

The problem is how to allow the VPN clients access to the 192.168.2.x network.

I can think of a few ways this might work:

1. Manually run a script that is triggered when the connection is made to add a route to the client
2. Policy route that allows the firewall to route traffic from source --> VPN SSL Pool to destination --> 192.168.2.x
3. Eliminate the separate router and use an unused interface on the UTM to route the traffic so the network can be considered "local." eth3 is not currently in use. The problem there (I think) is that currently all the local clients on the 192.168.1.x are using a static route on the current router to get to the 192.168.2.x network. So what happens if I eliminate that device and let the UTM route the traffic - i.e. since the current default gateway for these devices is 192.168.1.1 which is on the UTM, if I configure an interface for 192.168.2.x on the UTM, do the local clients no longer need a static route?

I could be totally wrong on any or all three of these, so please offer any ideas you may have on the best method. Obviously this needs to be as "hands-off" for the users as possible

Thanks


This thread was automatically locked due to age.
  • 0
    Hi,

    a. put the second network in "local networks" in the VPN settings
    and
    b. use a static or policy route so that the UTM knows how to reach the second network

    should work

    If you do your #3, you can get rid of all static routes and only do #a above.

    Barry
  • 0 in reply to BarryG
    Hi Barry, thank you for the reply.

    I already have the 2nd network in Local Networks in the VPN settings, so I decided to try that method first. I have a static route in place (Gateway) that says to get to network 2, use the interface on the network 1 side of the router, in this case 192.168.1.253. That works fine. The firewall itself can ping addresses in both networks without issue.

    With the live log open, I see this line:
    SENT CONTROL [user1]: 'PUSH_REPLY,route 10.242.2.1,topology net30,ping 10,ping-restart 120,route 192.168.2.0 255.255.255.0,route 192.168.1.0 255.255.255.0,dhcp-option DNS 192.168.1.6,dhcp-option DNS 192.168.2.6,dhcp-option WINS 192.168.1.6,dhcp-option DOMAIN mydomain.com,ifconfig 10.242.2.6 10.242.2.5' (status=1)

    So it looks like the UTM knows about the 192.168.2.0 route just as it does the 192.168.1.0.
    However, the VPN clients cannot ping anything in network 2. I have automatic firewall rule enabled. Do I need to do anything else you can think of to allow this traffic?
  • 0
    Hi, run a 'route' command on the VPN clients and see if they're getting the route set correctly.

    If they are not, make sure the client is running with admin rights in Windows.

    If they are, run tcpdump on the UTM and see if the pings are coming in and going out.

    Barry
  • 0
    You want a gateway route, not an interface route.  Route traffic to the IP of the other router.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson
    Yep that's what I have, but unfortunately it's still not working. At the moment I'm trying to figure out how to tcpdump as Barry suggested so I can see where the issue is.

    So to summarize, here's the current status:

    1. A UTM sits in Network 1, with internal IP 192.168.1.1
    2. A separate router has two interfaces, 192.168.1.253 and 192.168.2.253 (Network 2)
    3. Network 2 is connected with a Metro Ethernet to Network 1, using that router
    4. All devices in network 1 have a static route 192.168.2.0/24 -> 192.168.1.253
    5. All devices in network 2 have a static route 192.168.1.0/24 -> 192.168.2.253
    6. All devices in both networks can ping everything in the other network
    7. SSL VPN clients get an address from "SSL VPN Pool", such as 10.242.2.x. 
    8. Once connected, a VPN client device can ping any address in 192.168.1.x, but cannot ping any address in 192.168.2.x
    9. The UTM has a static (gateway type) route which is defined as Network: 192.168.2.0/24, and Gateway: 192.168.1.253. This seems to work as the UTM is able to ping anything in both networks.
    10. No policy Route is defined
    11. Both networks are defined as Local Networks in the settings for the SSL VPN

    Does that point out any incorrect settings?
  • 0
    Sorry, a typo in Item #2. Should say:
    2. A separate router has two interfaces, 192.168.1.253 and 192.168.2.253 (Network 2)
  • 0
    If looks like you have everything set up right but I suspect that you may be missing a route on the network 2 side. What do the Network 2 devices have as a default gateway? Or, do they have a static route back to the 10.242.2.x subnet used by your VPN clients?
  • 0
    Forgive me if I am completed wrong here, but this seems very similar to the issue I had trying to figure out how to have one subnet access multiple subnets through only one site2site tunnel.  for example, I wanted site A to access site C, and I currently have a tunnel between Site A to Site B, and Site B to Site C.  In your case, the VPN user would be site A, and you are wanting to access site C via Site B???  If this is correct, I was able to achieve this.  I did not need to manually create any type of routes.  All I did was add site C's local network to Site A's (your VPN's local networks), added the VPN's IP pool subnet to site C's tunnel to site B, and then sort of "criss-cross" on Site B's (adding Site A local network to tunnel to Site C, and adding Site C local network to tunnel to Site A)....  This is known as "hub & spoke" vpn topology.  I don't have my UTM interface in front of me at the moment, so I cannot be more accurate with my details, but let me know if you need more accurate details.

    I now realize I misunderstood your setup.  I was thinking you had a site2site tunnel between the two routers, but now see you said metro Ethernet.  But I think the same "hub & spoke" concept still applies.  If traffic is successfully being routed in both directions between 192.168.1.x and 192.168.2.x, then my guess would be maybe that you are missing 10.242.2.x on the separate router (so that if network 2 needs to "respond" back to VPN client, it knows to be routed through 192.168.1.x).  Example:  "All devices in network 2 have a static route 10.242.2.0/24 -> 192.168.2.253"...  I'm not an expert here, just figure things out by trial and error (hopefully not dropping entire network during the process).  [:)]
  • 0 in reply to tm-rimak
    Thanks guys for the replies. 

    You are correct that I had not thought to add the static route 10.242.2.0/24 -> 192.168.2.253 to the devices in the 192.168.2.x network so they would know how to get back. So that works. I believe the reason routing between 10.242.2.0 and 192.168.1.0 networks works  without having to do that to all of its devices is that 192.168.1.0 is truly a "local" network to the UTM, whereas 192.168.2.0 is not. That is, there is no interface on the UTM assigned to the 192.168.2.0 network.

    So one thing I'm looking at now is whether I can eliminate the additional router and just use an available interface on the UTM to route all of the traffic between the subnets. I think I can do that, I just have to figure it out and try it on the weekend when I won't affect everyone's work.

    Thank you again, this has been a very helpful discussion for me.
  • 0
    I'm guessing the reason the 192.168.1.0 hosts don't need a route is that they already have the UTM as their default gateway. 

    You should be able to replace your MetroE router using that additional UTM interface, but unless the 192.168.2.0 hosts also use the UTM as a default gateway then you will still need the static route to 10.242.2.0/24. If you really want to avoid the static route, then you'll probably have to look at setting up NAT, though that would probably be undesirable inside a network.
Unfiltered HTML