Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 6 replies
  • Subscribers 3 subscribers
  • Views 5194 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

Can't access remote network over IP Sec Site-to-Site VPN

Its Ecko

So I have this annoying problem that I signed up just to ask. I tried my best to find an open thread but didn't really find anything. Please let me know what I'm doing wrong!

I have two sites setup with the Sophos UTM 9 and successfully established the IPSec site-to-site VPN tunnel however when trying to access the remote networks, I'm unable to. I've tested this on Cisco devices with no problems but I'm new to Sophos so I may have overlooked something.

I'm not sure where to start but here are my networks:

Site 1 (Me) - 192.168.1.0/24
Site 2 (Remote) - 192.168.2.0/24

IPSec VPN site-to-site on both ends are up and my automatic firewall rules are in place so Any traffic is permitted in both directions

My SNAT rule on Site 1 is any network using any service going to internet ipv4 to change the source to the WAN address. No automatic firewall rule but manually created to allow internet access.
My SNAT rules on Remote is is any the internet network using any service going to internet ipv4 to change the source to the WAN address. Automatic firewall rule created.

The pings and http access isn't being blocked on either side in the firewall logs and I see SYN requests showing on my end triggering the NAT rule.

I don't have any static routes set.

I tested the pings from the gateway on either side with no success. I'm also able to login to the remote gateway via the admin console to make any config settings.

 

What an I missing?



This thread was automatically locked due to age.
Parents
  • 0

    Hi and welcome to the UTM Community!

    You have a whole new beast in front of you.  WebAdmin is a GUI that manipulates databases of objects and settings.  A single change there can cause the Configuration Daemon to rewrite hundreds of lines of the code used to run the UTM.  WebAdmin is capable of creating elegant, easy-to-maintain configurations, but not if you approach it as you would a Cisco.

    Agreed with Jason, you should need no SNATs.  WebAdmin will create all of the rules and routes you need if configured correctly.

    For the pinging issue, see #2 in Rulz (last updated 2019-04-17).

    Before looking at your configuration, do the following:

    1. Confirm that Debug is not enabled.
    2. Disable the IPsec Connection.
    3. Start the IPsec Live Log and wait for it to begin to populate.
    4. Enable the IPsec Connection.
    5. Show us about 60 lines from enabling through the error or IPsec SA established.

    Obfuscate IPs like 99.x.y.241 and 192.168.z.1

    Cheers - Bob

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

    Hi and welcome to the UTM Community!

    You have a whole new beast in front of you.  WebAdmin is a GUI that manipulates databases of objects and settings.  A single change there can cause the Configuration Daemon to rewrite hundreds of lines of the code used to run the UTM.  WebAdmin is capable of creating elegant, easy-to-maintain configurations, but not if you approach it as you would a Cisco.

    Agreed with Jason, you should need no SNATs.  WebAdmin will create all of the rules and routes you need if configured correctly.

    For the pinging issue, see #2 in Rulz (last updated 2019-04-17).

    Before looking at your configuration, do the following:

    1. Confirm that Debug is not enabled.
    2. Disable the IPsec Connection.
    3. Start the IPsec Live Log and wait for it to begin to populate.
    4. Enable the IPsec Connection.
    5. Show us about 60 lines from enabling through the error or IPsec SA established.

    Obfuscate IPs like 99.x.y.241 and 192.168.z.1

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Children
  • 0 in reply to BAlfson

    Well I'm only using SNAT (PAT) so that I can have my internal network have access to the outside world. I know that I don't need any NATing for the IPSec tunnel but I think that's what it's trying to do. I didn't do the automatic firewall rule when creating my SNAT entry but I have it to where all of my VLANs are being SNATed to my WAN address. But I DID do the automatic firewall rule for the IPSec connection so the ACL is in place.

    Here is my IPSec live log. I tried to remove my IP addresses from the log:

    2019:06:02-14:16:03 xk-gateway ipsec_starter[6658]: Starting strongSwan 4.4.1git20100610 IPsec [starter]...
    2019:06:02-14:16:04 xk-gateway pluto[6674]: Starting IKEv1 pluto daemon (strongSwan 4.4.1git20100610) THREADS VENDORID CISCO_QUIRKS
    2019:06:02-14:16:04 xk-gateway ipsec_starter[6665]: pluto (6674) started after 20 ms
    2019:06:02-14:16:04 xk-gateway pluto[6674]: loaded plugins: curl ldap aes des blowfish serpent twofish sha1 sha2 md5 random x509 pubkey pkcs1 pgp dnskey pem sqlite hmac gmp xauth attr attr-sql resolve
    2019:06:02-14:16:04 xk-gateway pluto[6674]: including NAT-Traversal patch (Version 0.6c)
    2019:06:02-14:16:04 xk-gateway pluto[6674]: Using Linux 2.6 IPsec interface code
    2019:06:02-14:16:04 xk-gateway pluto[6674]: loading ca certificates from '/etc/ipsec.d/cacerts'
    2019:06:02-14:16:04 xk-gateway pluto[6674]: loaded ca certificate from '/etc/ipsec.d/cacerts/VPN Signing CA.pem'
    2019:06:02-14:16:04 xk-gateway pluto[6674]: loading aa certificates from '/etc/ipsec.d/aacerts'
    2019:06:02-14:16:04 xk-gateway pluto[6674]: loading ocsp certificates from '/etc/ipsec.d/ocspcerts'
    2019:06:02-14:16:04 xk-gateway pluto[6674]: Changing to directory '/etc/ipsec.d/crls'
    2019:06:02-14:16:04 xk-gateway pluto[6674]: loading attribute certificates from '/etc/ipsec.d/acerts'
    2019:06:02-14:16:04 xk-gateway pluto[6674]: adding interface tun0/tun0 10.242.2.1:500
    2019:06:02-14:16:04 xk-gateway pluto[6674]: adding interface tun0/tun0 10.242.2.1:4500
    2019:06:02-14:16:04 xk-gateway pluto[6674]: adding interface eth1.69/eth1.69 x.x.x.x:500
    2019:06:02-14:16:04 xk-gateway pluto[6674]: adding interface eth1.69/eth1.69 x.x.x.x:4500
    2019:06:02-14:16:04 xk-gateway pluto[6674]: adding interface eth1.59/eth1.59 x.x.x.x:500
    2019:06:02-14:16:04 xk-gateway pluto[6674]: adding interface eth1.59/eth1.59 x.x.x.x:4500
    2019:06:02-14:16:04 xk-gateway pluto[6674]: adding interface eth1.49/eth1.49 x.x.x.x:500
    2019:06:02-14:16:04 xk-gateway pluto[6674]: adding interface eth1.49/eth1.49 x.x.x.x:4500
    2019:06:02-14:16:04 xk-gateway pluto[6674]: adding interface eth1.39/eth1.39 x.x.x.x:500
    2019:06:02-14:16:04 xk-gateway pluto[6674]: adding interface eth1.39/eth1.39 x.x.x.x:4500
    2019:06:02-14:16:04 xk-gateway pluto[6674]: adding interface eth1.29/eth1.29 x.x.x.x:500
    2019:06:02-14:16:04 xk-gateway pluto[6674]: adding interface eth1.29/eth1.29 x.x.x.x:4500
    2019:06:02-14:16:04 xk-gateway pluto[6674]: adding interface eth1.19/eth1.19 x.x.x.x:500
    2019:06:02-14:16:04 xk-gateway pluto[6674]: adding interface eth1.19/eth1.19 x.x.x.x:4500
    2019:06:02-14:16:04 xk-gateway pluto[6674]: adding interface eth1/eth1 x.x.x.x:500
    2019:06:02-14:16:04 xk-gateway pluto[6674]: adding interface eth1/eth1 x.x.x.x:4500
    2019:06:02-14:16:04 xk-gateway pluto[6674]: adding interface eth0/eth0 x.x.x.x (my utm):500
    2019:06:02-14:16:04 xk-gateway pluto[6674]: adding interface eth0/eth0 x.x.x.x (my utm):4500
    2019:06:02-14:16:04 xk-gateway pluto[6674]: adding interface lo/lo 127.0.0.1:500
    2019:06:02-14:16:04 xk-gateway pluto[6674]: adding interface lo/lo 127.0.0.1:4500
    2019:06:02-14:16:04 xk-gateway pluto[6674]: adding interface lo/lo ::1:500
    2019:06:02-14:16:04 xk-gateway pluto[6674]: loading secrets from "/etc/ipsec.secrets"
    2019:06:02-14:16:04 xk-gateway pluto[6674]: loaded PSK secret for x.x.x.x (my utm) x.x.x.x (remote utm)
    2019:06:02-14:16:04 xk-gateway pluto[6674]: listening for IKE messages
    2019:06:02-14:16:04 xk-gateway pluto[6674]: added connection description "S_xK-to-Site1"
    2019:06:02-14:16:04 xk-gateway pluto[6674]: "S_xK-to-Site1" #1: initiating Main Mode
    2019:06:02-14:16:04 xk-gateway pluto[6674]: "S_xK-to-Site1" #1: received Vendor ID payload [strongSwan]
    2019:06:02-14:16:04 xk-gateway pluto[6674]: "S_xK-to-Site1" #1: ignoring Vendor ID payload [Cisco-Unity]
    2019:06:02-14:16:04 xk-gateway pluto[6674]: "S_xK-to-Site1" #1: received Vendor ID payload [XAUTH]
    2019:06:02-14:16:04 xk-gateway pluto[6674]: "S_xK-to-Site1" #1: received Vendor ID payload [Dead Peer Detection]
    2019:06:02-14:16:04 xk-gateway pluto[6674]: "S_xK-to-Site1" #1: received Vendor ID payload [RFC 3947]
    2019:06:02-14:16:04 xk-gateway pluto[6674]: "S_xK-to-Site1" #1: enabling possible NAT-traversal with method 3
    2019:06:02-14:16:04 xk-gateway pluto[6674]: "S_xK-to-Site1" #1: NAT-Traversal: Result using RFC 3947: no NAT detected
    2019:06:02-14:16:04 xk-gateway pluto[6674]: "S_xK-to-Site1" #1: Peer ID is ID_IPV4_ADDR: 'x.x.x.x (remote utm)'
    2019:06:02-14:16:04 xk-gateway pluto[6674]: "S_xK-to-Site1" #1: Dead Peer Detection (RFC 3706) enabled
    2019:06:02-14:16:04 xk-gateway pluto[6674]: "S_xK-to-Site1" #1: ISAKMP SA established
    2019:06:02-14:16:04 xk-gateway pluto[6674]: "S_xK-to-Site1" #2: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP {using isakmp#1}
    2019:06:02-14:16:04 xk-gateway pluto[6674]: id="2203" severity="info" sys="SecureNet" sub="vpn" event="Site-to-site VPN up" variant="ipsec" connection="xK-to-Site1" address="x.x.x.x (my utm)" local_net="x.x.x.0/24" remote_net="x.x.x.0/24"
    2019:06:02-14:16:04 xk-gateway pluto[6674]: "S_xK-to-Site1" #2: sent QI2, IPsec SA established {ESP=>0x3a59ea90 <0x183c1518 DPD}
  • +1 in reply to Its Ecko

    The "culture" around the UTM normally uses Masquerading rules instead of SNATs for the purpose of sending traffic out with a public IP.  SNATs are commonly used with IPsec tunnels to move traffic into a tunnel that would not normally qualify for it.  That's why Jason and I were both unclear about what you were doing.

    Your tunnel establishes normally, so let's look at pictures of the Edits of the IPsec Connection and the Remote Gateway as well as the corresponding configurations from the other endpoint.  Also, the Edits of the objects in 'Local Networks' and 'Remote Networks'.

    Again, obfuscate IPs like 98.x.y.34.

    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

    My Cisco studies have failed me!

    Turns out that was the problem. I'm so used to doing SNAT with my Cisco hardware that the Masquerading thing I wasn't aware of with Sophos.

    It works like a charm now. It's good to learn a new product every now and then.

    Thanks for all the help guys!

Unfiltered HTML