User Authentication over S2S IPSec VPN

Hello,

The Sophos firewall does not support authentication for the Site to Site VPN communication (Assuming that you are trying to allow access of the resources to the authenticated users only from Site A to Site B and vice versa). This can be achieved with the remote access VPN, however that does not seems to be your requirement. 

Hi CV_Sophos , please provide below details:

* Since you mentioned that static route is being used, I am assuming your S2S IPSec is route based (tunnel type)? what are the local and remote subnets configured? is the IPsec tunnel is route based, is Any/Any being used as local/remote subnets in the IPsec tunnel config? please provide cli output of 'ipsec statusall' or provide the snapshot of info button (by clicking on it), you will get the subnets being used in the tunnel.

* "Each FW is setup with the local DC for user authentication" -  can you elaborate on this?  how is the user authenticating with xg330? are these users' ip address falling into the LAN subnet configured on both sides XG330?

May be its good to provide a clear topology of your network for us to understand your requirement better and suggest next steps.

Hi CV_Sophos , please provide below details:

* Since you mentioned that static route is being used, I am assuming your S2S IPSec is route based (tunnel type)? what are the local and remote subnets configured? is the IPsec tunnel is route based, is Any/Any being used as local/remote subnets in the IPsec tunnel config? please provide cli output of 'ipsec statusall' or provide the snapshot of info button (by clicking on it), you will get the subnets being used in the tunnel.

* "Each FW is setup with the local DC for user authentication" -  can you elaborate on this?  how is the user authenticating with xg330? are these users' ip address falling into the LAN subnet configured on both sides XG330?

May be its good to provide a clear topology of your network for us to understand your requirement better and suggest next steps.

Hello. Please see details below:

* Yes, the tunnel is route-based. The local/remote subnets are blank (several OS upgrades have resulted in improper GUI views). There is no [info] button for this connection (again probably due to something with a previous upgrade). CLI output for Site B (public IPs removed from listening list):

Status of IKE charon daemon (strongSwan 5.5.3, Linux 4.14.277, x86_64):
uptime: 124 days, since Mar 09 13:30:57 2024
malloc: sbrk 5935104, mmap 0, used 1036320, free 4898784
worker threads: 20 of 32 idle, 12/0/0/0 working, job queue: 0/0/0/0, scheduled: 9
loaded plugins: charon aes des rc2 sha2 sha3 sha1 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf curve25519 xcbc cmac hmac attr kernel-netlink socket-default stroke vici xauth-generic xauth-access-server ippool-access-server cop-updown garner-logging ha error-notify unity
Listening IP addresses:
169.254.234.5
10.254.2.1
172.16.16.15
10.70.1.1
10.1.1.3
10.1.9.49
10.1.10.1
10.1.9.113
10.1.30.1
10.1.30.5
10.1.30.9
10.1.8.1
10.1.20.1
10.1.9.81
10.1.0.1
10.1.2.1
10.1.4.1
10.1.5.1
10.1.6.1
10.1.7.1
10.1.12.1
10.1.16.1
10.1.70.1
10.1.80.1
10.1.84.1
10.1.9.1
10.1.9.17
10.1.9.33
10.1.99.1
10.1.11.1
10.254.2.5
10.81.234.1
2001:db8::
10.1.4.129
Connections:
VPN_RMP_EPL-1: 10.254.2.1...10.254.2.2 IKEv2, dpddelay=30s
VPN_RMP_EPL-1: local: [10.254.2.1] uses pre-shared key authentication
VPN_RMP_EPL-1: remote: [10.254.2.2] uses pre-shared key authentication
VPN_RMP_EPL-1: child: 0.0.0.0/0 === 0.0.0.0/0 TUNNEL, dpdaction=clear
VPN_RMP_EPL-2: child: ::/0 === ::/0 TUNNEL, dpdaction=clear
Security Associations (2 up, 0 connecting):
VPN_RMP_EPL-1[10517]: ESTABLISHED 25 minutes ago, 10.254.2.1[10.254.2.1]...10.254.2.2[10.254.2.2]
VPN_RMP_EPL-1[10517]: IKEv2 SPIs: 235121e00525375b_i 4374f8f526d065d1_r*, rekeying in 52 minutes
VPN_RMP_EPL-1[10517]: IKE proposal: AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/CURVE_25519
VPN_RMP_EPL-1{11139}: INSTALLED, TUNNEL, reqid 10, ESP SPIs: c695f115_i c255b365_o
VPN_RMP_EPL-1{11139}: AES_CBC_256/HMAC_SHA2_512_256/CURVE_25519, 116469911 bytes_i (555629 pkts, 966s ago), 1224491927 bytes_o (1136245 pkts, 0s ago), rekeying in 11 minutes
VPN_RMP_EPL-1{11139}: 0.0.0.0/0 === 0.0.0.0/0
VPN_RMP_EPL-2{11141}: INSTALLED, TUNNEL, reqid 9, ESP SPIs: c76199ee_i cb72ac86_o
VPN_RMP_EPL-2{11141}: AES_CBC_256/HMAC_SHA2_512_256/CURVE_25519, 0 bytes_i, 0 bytes_o, rekeying in 38 minutes
VPN_RMP_EPL-2{11141}: ::/0 === ::/0

* Both Site A and Site B have their own domain controller that is on the same domain. Users are currently authenticated with AD using the DC at the Site the FW is using.

* There are two locations. Site A has a network of 10.1.0.0/16 and Site B has a network of 10.2.0.0/16. Both sites have a static route that routes the other site's network over the S2S VPN. The configuration is similar to a H where each location is siloed and could be independent from the other, but the cross-site connection is there for the backend (DC and file server replications, etc) and for IT Management to access resources from their PC and not have to use a jump server local to that site.

*** What I am trying to accomplish is populating the username field for incoming requests across the VPN interface (below is a screenshot of the log from Site B that would have a username populated if the endpoint was on the local network or connected to the FW via SSL VPN, however, this endpoint is across the S2S VPN and located at Site A). Locally on the FWs this is done successfully whether the user is connected via SSL VPN or via one of the LAN networks. If there is a better way to setup our S2S, please advise.

Thank you,

James

Could you please DM me, we can chat on this further and have a call if required.

Hi CV_Sophos , Based on further one on one discussion, realised you are trying out to keep userA or userB in the 'Match known users' filed of the associated Firewall rule (source zones: lan,vpn,    destination zones: vpn,lan) to allow/deny traffic from the users into the VPN. 

This is not possible, at least in the Strongswan based VPN implementation on SFOS we don't take user into account to allow/deny traffic into S2S VPN (policy based or route based). There is no user authentication that happens in S2S VPN tunnel. Placement of traffic into VPN is based on firewall rule with zones/networks and local/remote subnets in the IPsec config or using static/dynamic routing in route based VPN.

userA-------LAN----SFOS1---------IPSec--------SFOS2-----LAN------userB; in your topology of this sort, when userA sends traffic to userB, firewall rule on SFOS1 set with  'Match known users' causes the packets dropped on SFOS1 itself and packet will not be placed onto the s2s IPsec VPN tunnel.

'Match known users' filed is applicable and works fine while having remote access IPsec that has user Authentication for a given user.

Using STAS you should be able to tell both firewalls the identity of an IP/USER - combination.

https://docs.sophos.com/nsg/sophos-firewall/20.0/Help/en-us/webhelp/onlinehelp/AdministratorHelp/Authentication/STAS/index.html

 dirkkotte , thank you for the suggestion. I have considered STAS, but with what looks to be a requirement to have all traffic "user authenticated", it would provide a significant amount of overhead to manage as we have several services/systems/environments that would be considered "unauthenticated" as they are not associated with internal AD domain. Thank you again for the suggestion and I do believe it would work in scenario, but since we are growing our non-domain devices faster and are shifting to a ZTNA design, this would be a short-lived solution.

James

Sreenivasulu Naidu , as discussed in our PMs, this concept of enabling "match known users" automatically drops traffic going into a VPN is completely not true. I a successfully confirmed that we have several FW rules on SFOS1 that are sourced with the local LAN and a destination on the SFOS2 local LAN that work perfectly fine with 'match known users' enabled and configured. This same configuration is working fine going the other way with SFOS2 -> SFOS1. However, the user authentication doesn't get passed to the second FW. I believe that STAS would solve this issue, but in the end will be short-lived as we are switching to a ZTNA architecture with hot-desks and no client internal LAN. Thank you again for your assistance through our discussions.

James