S2S - no connection to remote server

Hey,

I would like to connect to a remote server via VPN. The s2s connection works but Iam unable to reach the server on the other side (the remote site is one host only).

I can see that the outgoing traffic goes through the firewall rule LAN to WAN, if I will connect from the local subnet 172.20./16 to the remote server 172.20.200.49.

So whats missing / wrong? Do I have to create a further rule/route - where ?

Thanks in advance!

  • Hi  

    As per the details provided, you want to access the server which is behind the XG firewall and you are connecting through SSL VPN but unable to connect the server.

    Please provide us with more details on connectivity.

    How remote server is connected with the XG firewall?

    Is LAN to VPN and VPN to LAN firewall rules are created or for the zone where the server is located? 

  • In reply to Keyur:

    Hi Keyur, 

    I would like to connect to a remote server via site2site vpn. From a local subnet (XG firewall) to a remote server behind a Sonicwall firewall.

    Greetings

    Philipp

  • In reply to Philipp Marx:

    Hi  

    Please refer to the article and configure the IPsec tunnel between Sophos XG and Sonicwall firewall.

    Establish an IPsec connection between Sophos XG Firewall and SonicWall.

  • In reply to Keyur:

    Hey Keyur, 

    the vpn is connected with the specifications from the customer.

    [IKE] scheduling rekeying in 28413s

    [IKE] maximum IKE_SA lifetime 28773s
    [IKE] CHILD_SA xyzvpn-1{33697} established with SPIs cedb80c2_i fd6079c2_o and TS 10.200.206.0/24 === 172.27.200.49/32
    [APP] [SSO] (sso_invoke_once) SSO is disabled.
    [APP] [COP-UPDOWN] (ref_counting) ref_count: 0 to 1 ++ up ++ (10.200.206.0/24#172.27.200.49/32)
    [APP] [COP-UPDOWN] (ref_counting_remote) ref_count_remote: 0 to 1 ++ up ++ (193.218.xxx.xxx#217.6.xxx.xxx)
    [APP] [COP-UPDOWN] (cop_updown_invoke_once) UID: 33768 Net: Local 193.218..xxx.xxx Remote 217.6.xxx.xxx Connection: xyzvpn Fullname: xyzvpn-1
    [APP] [COP-UPDOWN] (cop_updown_invoke_once) Tunnel: User '' Peer-IP '' my-IP '' up-client
    initiate completed successfully

    Maybe there is a routing problem from our local subnet "172.20.0.0" over the "local vpn subnet 10.200.206.0" (using NAT) to the "remote server 172.27.200.49"?!

    regards

    Philipp

  • In reply to Philipp Marx:

    Hi  

    Please disable the NAT in Gateway settings.

    Make sure LAN to VPN and VPN to LAN firewall rules are configured.

    Please enable "MASQ" in LAN to VPN rule.

  • In reply to Keyur:

    Hi Keyur, 

    maybe could you please explain in more detail.

    Thanks! 

  • In reply to Philipp Marx:

    Hi  

    Please see the attached screenshot and disable NAT configuration



    Please create firewall rules LAN to VPN and VPN to LAN.

    Please enable "MASQ" oprion in LAN to VPN rule.

  • In reply to Keyur:

    Hi Keyur, 

    we have disabled the nat rule in the vpn gateway settings. 

    Then we have updated the firewall rule for LAN to VPN.

    The "local" remote subnet 10.200.x.x is used for the vpn connection and is configured under "host and services > IP Host" only.

    For our understanding we have to create a route for our local working subnet 172.20.x.x into the 10.200.x.x as well?! 

    We can see that the outgoing traffic to 172.27.200.49 still goes through the "internal > wan" rule. 

     

  • In reply to Philipp Marx:

    Hi  

    Could you please let me below details?

    The IP address/Network behind the XG firewall wants to access the server at a remote location.

    Remote server IP address/Network.

    In the screenshot of the firewall rule, in the Source Network, you have defined two networks 172.20.0.0 and 10.200.206.0

    In the IPsec configuration, you have added network 172.20.0.0/16 

  • There are two possible issues there:

    • To support federation / s2s, an XMPP server must be available on the internet, and not associated to a local IP. Ideally, you should have set DNS SRV record for that XMPP service.
    • The second issue seems that your DNS resolution seems incorrect as ejabberd gets a local address for the domain from your DNS, when you seem to expect a public IP. You need to make sure the DNS service on the XMPP server is set up and properly working.
  • In reply to Keyur:

    Hi Keyur, 

    first, thanks for your time!!

    May be this graphic will help to understand the problem:

     

    The gateway VPN IPSec configuration is as follows: 

    The Firewall Rule LAN to VPN:

    VPN to LAN:

    Regards 

    Philipp

  • In reply to Philipp Marx:

    Hi  

    Thank for providing the details diagram.

    Is there any specific requirement to use a 10.200.206.0/24 network for VPN communication?

    We can get it to work by adding network 172.20.0.0/16 as Local subnet and 172.27.200.49/32 as a remote subnet in the IPsec VPN configuration.

    If routes are added for the network 172.20.0.0/16 in XG firewall and it's reachable (I am assuming it is).

    In LAN to VPN rule, you do not require to specify any network, keep it "ANY" for Source and Destination network.

    Second Scenario

    If you wish to NAT the traffic of the network 172.20.0.0/16 with 10.200.206.0/24

    In the IPsec configuration

    Local Subnet - 172.20.0.0/16

    Remote Subnet- 172.27.200.49/32

    Enable NAT- It will show 172.20.0.0/16 by default and NAT to select 10.200.206.0/24

    It will NAT outbound VPN traffic from 172.20.0.0/16 network to 10.200.206.0/24 network



    Y
    ou can use troubleshooting guide- https://community.sophos.com/kb/en-us/123320

  • In reply to Keyur:

    Hello Keyur, 

    first scenario: 

    yes, that are requirements from our customer. But I will ask him if we could change the subnet. 

    second:

    The problem is if we change the local subnet to 172.20.x.x instead of 100.200.x.x the vpn connection will not come up. We could verify it with our customer that for the authentication we had to use the 100.200.x.x. network. Therefore the second scenario will not work. 

  • In reply to Spencer James:

    We switched from Sonicwall to XG last month. Therefore it was no problem to get a working VPN connection with these configuration details.