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

Routing-Issue with IPsec S2S-VPN and RA-SSL VPN

I have the following interfaces:

 

Inside Network on eth4.

Outside Network on eth1.

 

I already have a working IPSec Site-to-Site tunnel which passes any traffic coming from the inside Network to our datacenter (where we have the internet-breakout and a internal Server Network).

(Traffic from the inside Network directed to "Internet IPv4" is sent into the tunnel).

 

I also have a SSL RA client VPN with split-Tunneling.

The Remote Access Profile is set up to get access to the inside Network and the Datacenter Networks (which are reachable through the S2S-tunnel).

With this setup i have a kind of routing-issue:

What is working:

  • traffic from the inside-Network to the datacenter or internet is set correctly throughout the S2S-VPN
  • The datacenter-network is able to access the inside-Network through the S2S-VPN
  • The VPN Client is able to access the Datacenter-network

What is not working:

  • The VPN-Client is not able to access the inside-network

Observations:

  • tcpdump shows that the packets destined for the inside-network are sent out to eth1 instead of eth4.
  • When the S2S-VPN is switched off, the VPN-Client has access to the inside-Network. tcpdump shows that the packets are sent to eth4.
  • Using a Policy-route from the VPN-Client Adress-Range to the inside network we can see that the packets are then sent out on the inside interface eth4.
    ping is replied from the target, tcpdump shows that the icmp-replys are sent out on eth1. But they do not reach the vpn-client. They are also not sent into the S2S-Tunnel.

Do you have any idea how to make this setup working so that the VPN-Client is able to access the inside-network?



This thread was automatically locked due to age.
Parents
  • Hi, Carsten, and welcome to the UTM Community!

    Please show pictures of the Edits of the IPsec Connection, Remote Gateway, the SSL VPN Profile and the related Policy Route(s).

    Cheers - Bob

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

    here are the pictures.

    When the IPSec Tunnel is switched off, the connection to the internal LAN OFFICE Network is working without the policy-route.

    In the past the S2S-tunnel did not have the "internet ipv4"-route, it had only access to the networks in the datacenter. At this stage we had access from the SSL-VPN to the LAN OFFICE Network. It stopped working when we changed the VPN to route any traffic to the internet via the IPsec tunnel.

     

     

  • I would not select 'Strict routing' in the IPsec Connection.  See if that lets you eliminate your Policy Route.

    Interesting.  Just out of curiosity, why send all external traffic via the data center?

    Cheers - Bob

    PS You said:

    • Using a Policy-route from the VPN-Client Adress-Range to the inside network we can see that the packets are then sent out on the inside interface eth4.
      ping is replied from the target, tcpdump shows that the icmp-replys are sent out on eth1. But they do not reach the vpn-client. They are also not sent into the S2S-Tunnel.

    I'm confused about who's pinging what from where.  No need to explain if things are working as you want.

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • When i set up the IPsec Connection i tried use the configuration without the 'strict routing' option. Without this option i got a lot of trouble at the moment the IPSec tunnel is connected: we lost remote administration access and even the SSL-Client was no longer able to connect. I am assuming that the UTM tried to route even the SSL-Client VPN traffic and the remote Management-traffic through the S2S-VPN.

     

    This UTM is part of a company network with multiple locations (most of them are Cisco ASA-based). As a part of the security profile and for centralization it has been decided to use a single internet-breakout for the entire company.

     

    To explain the packet flow with the policy-route. This is what we see with tcpdump:

    With policy-route:

    icmp from the vpn-client
    (SSL-VPN-Client)->(outside ETH1)->(UTM)->(lan office ETH4)->(inside host)

    then the inside host replys
    (inside host)->(lan office ETH4)->(UTM)->(outside ETH1)->? (not sent to the SSL-VPN-Client)

     

    utm01:/root # tcpdump -ni any -e host 192.168.178.36 and icmp

    12:45:20.951569  In ethertype IPv4 (0x0800), length 76: 10.242.2.2 > 192.168.178.36: ICMP echo request, id 1, seq 568, length 40
    12:45:20.951601 Out 00:xx:xx:xx:xx:04 ethertype IPv4 (0x0800), length 76: 10.242.2.2 > 192.168.178.36: ICMP echo request, id 1, seq 568, length 40
    12:45:20.952064  In 00:xx:xx:xx:xx:bf ethertype IPv4 (0x0800), length 76: 192.168.178.36 > 10.242.2.2: ICMP echo reply, id 1, seq 568, length 40
    12:45:20.952454 Out 00:xx:xx:xx:xx:01 ethertype IPv4 (0x0800), length 76: 192.168.178.36 > 10.242.2.2: ICMP echo reply, id 1, seq 568, length 40

     

    Without policy-route:

    icmp from the vpn-client
    (SSL-VPN-Client)->(outside ETH1)->(UTM)->(outside ETH1)

     

    utm01:/root # tcpdump -ni any -e host 192.168.178.36 and icmp

    12:48:19.498861  In ethertype IPv4 (0x0800), length 76: 10.242.2.2 > 192.168.178.36: ICMP echo request, id 1, seq 572, length 40
    12:48:19.498887 Out 00:xx:xx:xx:xx:01 ethertype IPv4 (0x0800), length 76: 10.242.2.2 > 192.168.178.36: ICMP echo request, id 1, seq 572, length 40

    00:xx:xx:xx:xx:01 = eth01
    00:xx:xx:xx:xx:04 = eth04
    00:xx:xx:xx:xx:bf = inside host
    10.242.2.2 = SSL VPN Client ip
    192.168.178.36 = inside host

  • It sounds like you need Strict Routing because you have a mixture of encrypted and unencrypted traffic between the two sides of the IPsec S2S.  Another solution to that might have been to add the endpoint Public IPs to the IPsec tunnel, thus eliminating unencrypted traffic.  That would let you eliminate Strict Routing so that everything would work fine and you wouldn't need the Policy Route.

    I'm still confused about why the SSL VPN Client could have trouble with a local resource, but not with those reached through the IPsec tunnel.  For your final problem with ICMP, I don't see how you can route the return traffic with a Route (no interface) or a NAT rule.  You might try a Policy Route like:

    Gateway : LAN OFFICE -> {IP Protocol 1} -> VPN Pool (SSL) : {10.242.2.1}

    I've not tried that before and am pessimistic about its success.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Reply
  • It sounds like you need Strict Routing because you have a mixture of encrypted and unencrypted traffic between the two sides of the IPsec S2S.  Another solution to that might have been to add the endpoint Public IPs to the IPsec tunnel, thus eliminating unencrypted traffic.  That would let you eliminate Strict Routing so that everything would work fine and you wouldn't need the Policy Route.

    I'm still confused about why the SSL VPN Client could have trouble with a local resource, but not with those reached through the IPsec tunnel.  For your final problem with ICMP, I don't see how you can route the return traffic with a Route (no interface) or a NAT rule.  You might try a Policy Route like:

    Gateway : LAN OFFICE -> {IP Protocol 1} -> VPN Pool (SSL) : {10.242.2.1}

    I've not tried that before and am pessimistic about its success.

    Cheers - Bob

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