Guest User!

You are not Sophos Staff.

Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 27 subscribers
  • Views 40746 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

Trying to create an IPsec VPN between two XG Firewalls. Am I missing something?

Rohan Noyes

I've been trying, unsuccessfully, to create a IPsec VPN between two Sophos XG firewalls. The IPsec VPN is apparently established but there is no traffic flow between the networks. Ping tests to the LAN IP of the remote XG firewall, and remote other devices, fails. Traceroutes fail at the first hop.

One XG is a virtual machine, the other is a software based install. Both firewalls are running SFOS 16.01.0, but I couldn't establish the connection in SFOS 15.01.0 MR-3 either. Both firewalls are directly connected to the internet.

Branch Office - Subnet: 192.168.192.0/24 - XG: 192.168.192.251
Head Office - Subnet: 192.168.32.0/24  - XG: 192.168.31.201

Head Office IPsec Config

Name: Lab_To_Home_IPsec
Connection Type: Site-to-Site
Policy: DefaultHeadOffice
Action of VPN Restart: Respond Only
Authentication Type Preshared Key

Local Endpoint Details: Port2 (Head Office Public IP)
Remote Endpoint Details: Branch Office Public IP

IP Family: IPv4
Local Subnet: 192.168.31.0/24 (not NATed)
Local ID: IP Address - Head Office Public IP
Remote LAN Network: 192.168.192.0/24
Remote ID: IP Address - Branch Office Public IP

User Authentication Mode: Disabled
Protocol: All
Disconnect when tunnel is idle: Not enabled

Branch Office IPsec Config

Name: Home_to_Lab_IPsec
Connection Type: Site-to-Site
Policy: DefaultBranchOffice
Action of VPN Restart: Initiate
Authentication Type Preshared Key

Local Endpoint Details: PortB (Branch Office Public IP)
Remote Endpoint Details: Head Office Public IP

IP Family: IPv4
Local Subnet: 192.168.192.0/24 (not NATed)
Local ID: IP Address - Branch Office Public IP
Remote LAN Network: 192.168.31.0/24
Remote ID: IP Address - Head Office Public IP

User Authentication Mode: Disabled
Protocol: All
Disconnect when tunnel is idle: Not enabled

Troubleshooting tried so far: 

Below are some logs and console outputs that hopefully will help! Let me know if there's any further information I can provide.

I thank anyone in advance that might be able to assist.

 

Head Office IPsec Status

Head Office /log/ipsec.log

Oct 06 15:32:47 "Lab_To_Home_IPsec-1" #8: responding to Main Mode
Oct 06 15:32:47 "Lab_To_Home_IPsec-1" #8: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Oct 06 15:32:47 "Lab_To_Home_IPsec-1" #8: STATE_MAIN_R1: sent MR1, expecting MI2
Oct 06 15:32:47 "Lab_To_Home_IPsec-1" #8: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): no NAT detected
Oct 06 15:32:47 "Lab_To_Home_IPsec-1" #8: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Oct 06 15:32:47 "Lab_To_Home_IPsec-1" #8: STATE_MAIN_R2: sent MR2, expecting MI3
Oct 06 15:32:47 "Lab_To_Home_IPsec-1" #8: Main mode peer ID is ID_IPV4_ADDR: 'XX.XX.XX.XX'
Oct 06 15:32:47 "Lab_To_Home_IPsec-1" #8: I did not send a certificate because I do not have one.
Oct 06 15:32:47 "Lab_To_Home_IPsec-1" #8: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Oct 06 15:32:47 "Lab_To_Home_IPsec-1" #8: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_128 prf=oakley_md5 group=modp1024}
Oct 06 15:32:47 "Lab_To_Home_IPsec-1" #8: Dead Peer Detection (RFC 3706): enabled
Oct 06 15:32:47 "Lab_To_Home_IPsec-1" #9: responding to Quick Mode {msgid:df67d6ae}
Oct 06 15:32:47 "Lab_To_Home_IPsec-1" #9: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Oct 06 15:32:47 "Lab_To_Home_IPsec-1" #9: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
Oct 06 15:32:48 "Lab_To_Home_IPsec-1" #9: up-client output: success
Oct 06 15:32:48 "Lab_To_Home_IPsec-1" #9: Dead Peer Detection (RFC 3706): enabled
Oct 06 15:32:48 "Lab_To_Home_IPsec-1" #9: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Oct 06 15:32:48 "Lab_To_Home_IPsec-1" #9: STATE_QUICK_R2: IPsec SA established {ESP=>0x1d197141 <0xfd24a003 xfrm=AES_128-HMAC_MD5 IPCOMP=>0x000095a4 <0x000054f7 NATD=none DPD=enabled}

Head Office ifconfig ipsec 0

ipsec0 Link encap:Ethernet HWaddr 62:25:62:D9:C5:FF
inet addr:169.254.234.5 Bcast:0.0.0.0 Mask:255.255.255.255
inet6 addr: fe80::6025:62ff:fed9:c5ff/64 Scope:Link
UP BROADCAST RUNNING NOARP MULTICAST MTU:16260 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

Head Office ip route list

XX.XX.XX.XX/27 dev Port2 proto kernel scope link src XX.XX.XX.XX
192.168.31.0/24 dev Port1 proto kernel scope link src 192.168.31.201
192.168.192.0/24 dev ipsec0 scope link

Head Office system route_precedence show

Routing Precedence:
1. Policy routes
2. VPN routes
3. Static routes

Head Office system ipsec_route show

 

tunnelname host/network netmask
Lab_To_Home_IPsec 192.168.192.0 255.255.255.0

 

Branch Office IPsec Status

Branch Office /log/ipsec.log

Oct 06 15:32:47 "Home_to_Lab_IPsec-1" #19: initiating Main Mode
Oct 06 15:32:47 "Home_to_Lab_IPsec-1" #19: received Vendor ID payload [Dead Peer Detection]
Oct 06 15:32:47 "Home_to_Lab_IPsec-1" #19: received Vendor ID payload [RFC 3947] method set to=110
Oct 06 15:32:47 "Home_to_Lab_IPsec-1" #19: received Vendor ID payload [Cisco-Unity]
Oct 06 15:32:47 "Home_to_Lab_IPsec-1" #19: enabling possible NAT-traversal with method RFC 3947 (NAT-Traversal)
Oct 06 15:32:47 "Home_to_Lab_IPsec-1" #19: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
Oct 06 15:32:47 "Home_to_Lab_IPsec-1" #19: STATE_MAIN_I2: sent MI2, expecting MR2
Oct 06 15:32:47 "Home_to_Lab_IPsec-1" #19: I did not send a certificate because I do not have one.
Oct 06 15:32:47 "Home_to_Lab_IPsec-1" #19: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): no NAT detected
Oct 06 15:32:47 "Home_to_Lab_IPsec-1" #19: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
Oct 06 15:32:47 "Home_to_Lab_IPsec-1" #19: STATE_MAIN_I3: sent MI3, expecting MR3
Oct 06 15:32:47 "Home_to_Lab_IPsec-1" #19: Main mode peer ID is ID_IPV4_ADDR: 'XX.XX.XX.XX'
Oct 06 15:32:47 "Home_to_Lab_IPsec-1" #19: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4
Oct 06 15:32:47 "Home_to_Lab_IPsec-1" #19: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_128 prf=oakley_md5 group=modp1024}
Oct 06 15:32:47 "Home_to_Lab_IPsec-1" #19: Dead Peer Detection (RFC 3706): enabled
Oct 06 15:32:47 "Home_to_Lab_IPsec-1" #20: initiating Quick Mode PSK+ENCRYPT+COMPRESS+TUNNEL+PFS+UP+failureDROP {using isakmp#19}
Oct 06 15:32:47 "Home_to_Lab_IPsec-1" #20: up-client output: success
Oct 06 15:32:48 "Home_to_Lab_IPsec-1" #20: Dead Peer Detection (RFC 3706): enabled
Oct 06 15:32:48 "Home_to_Lab_IPsec-1" #20: transition from state STATE_QUICK_I1 to state STATE_QUICK_I2
Oct 06 15:32:48 "Home_to_Lab_IPsec-1" #20: STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0xfd24a003 <0x1d197141 xfrm=AES_128-HMAC_MD5 IPCOMP=>0x000054f7 <0x000095a4 NATD=none DPD=enabled}

Branch Office ifconfig ipsec 0

ipsec0 Link encap:Ethernet HWaddr 6A:44:9D:57:3B:BF
inet addr:169.254.234.5 Bcast:0.0.0.0 Mask:255.255.255.255
inet6 addr: fe80::6844:9dff:fe57:3bbf/64 Scope:Link
UP BROADCAST RUNNING NOARP MULTICAST MTU:16260 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

Branch Office ip route list

10.255.0.0/24 dev GuestAP proto kernel scope link src 10.255.0.1
XX.XX.XX.XX/18 dev PortB proto kernel scope link src XX.XX.XX.XX
192.168.31.0/24 dev ipsec0 scope link
192.168.32.0/24 via 192.168.192.250 dev PortA proto static
192.168.92.0/24 dev PortC proto kernel scope link src 192.168.92.254
192.168.192.0/24 dev PortA proto kernel scope link src 192.168.192.251

Branch Office system route_precedence show

Routing Precedence:
1. Policy routes
2. VPN routes
3. Static routes

Branch Office system ipsec_route show

tunnelname host/network netmask
Home_to_Lab_IPsec 192.168.31.0 255.255.255.0



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

    Hi Rohan,

    Sorry to hear you're having trouble with the IPSEC beast and scanning over your logs and the very information post you've made (ultra fab) everything looks ok.

    Your tunnel is established as per your screenshot and i think the problem is getting the traffic running of which i think is solely a firewall issue or a routing to/through the XG issue.

    When in Advanced Console through option 5 and option 3 when connected in SSH, can you do the following TCPDump?

    tcpdump -veni ipsec0

    That should show all the traffic entering and exiting the ipsec tunnel and you can do this on both XGs :)

    If you dont see anything, set up a recurring ping to something on the remote side from an endpoint and change your tcpdump to the following:

    tcpdump -veni any host <ipofendpointsendingping> and icmp

    This listens on any interface for a host IP sending icmp packets.

    Just to see whether these packets are getting to the right places initially :)

    Emile

Reply
  • 0

    Hi Rohan,

    Sorry to hear you're having trouble with the IPSEC beast and scanning over your logs and the very information post you've made (ultra fab) everything looks ok.

    Your tunnel is established as per your screenshot and i think the problem is getting the traffic running of which i think is solely a firewall issue or a routing to/through the XG issue.

    When in Advanced Console through option 5 and option 3 when connected in SSH, can you do the following TCPDump?

    tcpdump -veni ipsec0

    That should show all the traffic entering and exiting the ipsec tunnel and you can do this on both XGs :)

    If you dont see anything, set up a recurring ping to something on the remote side from an endpoint and change your tcpdump to the following:

    tcpdump -veni any host <ipofendpointsendingping> and icmp

    This listens on any interface for a host IP sending icmp packets.

    Just to see whether these packets are getting to the right places initially :)

    Emile

Children
  • 0 in reply to Emile Belcourt

    Hi Emile!

    Thanks for helping out so quickly. With your help I've discovered that the VPN is (kind of) working. I'll run through my thought process in case it helps someone in the future.

    When pinging from the branch to head office I see the following displayed with tcpdump -veni ipsec0 on the head office XG console:

    17:56:42.440419 ipsec0, IN: 00:23:04:bb:8e:90 > 00:1b:21:36:05:86, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 127, id 23234, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.192.76 > 192.168.31.201: ICMP echo request, id 1, seq 2101, length 40
    17:56:46.953129 ipsec0, IN: 00:23:04:bb:8e:90 > 00:1b:21:36:05:86, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 127, id 23245, offset 0, flags [none], proto ICMP (1), length 60)

    Nothing is displayed with tcpdump -veni ipsec0 on the branch office XG console.

    When pinging from the head to branch office I see the following displayed with tcpdump -veni ipsec0 on the branch office XG console:

    18:06:28.406485 ipsec0, IN: 1c:6a:7a:81:1b:d9 > 00:0c:29:bb:8a:75, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 32362, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.31.201 > 192.168.192.251: ICMP echo request, id 39228, seq 0, length 64
    18:06:29.415425 ipsec0, IN: 1c:6a:7a:81:1b:d9 > 00:0c:29:bb:8a:75, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 32426, offset 0, flags [DF], proto ICMP (1), length 84)

    Nothing is displayed with tcpdump -veni ipsec0 on the head office XG console.

    The same is experienced with tcpdump -veni any host 192.168.192.251 and icmp and tcpdump -veni any host 192.168.31.201 and icmp respectively.

     

    This made me realise that the traffic was making it to the remote site from both firewalls. Checking the Networking > Zones config I realised that the VPN zones only have SNMP access to the XGs (something that I don't think can be modified). After choosing different ping targets at each side I started to see responses and the traffic was incrementing on the VPN firewall rules.

    Moving forward I tried to access a HTTP page of a device at the branch office from head office, but it didn't work. The tcpdump -veni ipsec0 on the head office XG console showed the following:

    18:29:38.349159 ipsec0, OUT: 62:25:62:d9:c5:ff > 62:25:62:d9:c5:ff, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 26889, offset 0, flags [DF], proto TCP (6), length 52)
     169.254.234.5.45708 > 192.168.192.111.80: Flags [S], cksum 0xb4d4 (correct), seq 2425399634, win 32440, options [mss 16220,nop,nop,sackOK,nop,wscale 7], length 0
    18:29:39.345237 ipsec0, OUT: 62:25:62:d9:c5:ff > 62:25:62:d9:c5:ff, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 26890, offset 0, flags [DF], proto TCP (6), length 52)
     169.254.234.5.45708 > 192.168.192.111.80: Flags [S], cksum 0xb4d4 (correct), seq 2425399634, win 32440, options [mss 16220,nop,nop,sackOK,nop,wscale 7], length 0
    18:29:41.349279 ipsec0, OUT: 62:25:62:d9:c5:ff > 62:25:62:d9:c5:ff, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 26891, offset 0, flags [DF], proto TCP (6), length 52)
     169.254.234.5.45708 > 192.168.192.111.80: Flags [S], cksum 0xb4d4 (correct), seq 2425399634, win 32440, options [mss 16220,nop,nop,sackOK,nop,wscale 7], length 0
    18:29:45.357251 ipsec0, OUT: 62:25:62:d9:c5:ff > 62:25:62:d9:c5:ff, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 26892, offset 0, flags [DF], proto TCP (6), length 52)
     169.254.234.5.45708 > 192.168.192.111.80: Flags [S], cksum 0xb4d4 (correct), seq 2425399634, win 32440, options [mss 16220,nop,nop,sackOK,nop,wscale 7], length 0

    Nothing is displayed with tcpdump -veni ipsec0 on the head office XG console. No denied entries showed up in the firewall log. 

    I notice that the source address in the tcpdump above is the local-link address of the ipsec0 interface. Could that be causing the problem?

    Thanks again for your help!

  • 0 in reply to Rohan Noyes

    Rohan,

    have a look at the second method from this KB: https://community.sophos.com/kb/en-us/123334

    You could even use a Red to Red configuration between the 2 XG.

  • 0 in reply to lferrara

    Hi Luk,

    Thanks for the info. I hadn't thought of using RED between the two XGs. I have followed the steps in the linked article previously.

    The more I look I think the VPN may actually be working, I only have two devices running on the head office network which is limiting my testing.

    Is there away to enable more Sophos XG features for the VPN zone? The manage link is disabled for me.

    Thanks,

    Rohan.

  • +1 in reply to Rohan Noyes

    Rohan,

    you can enable other XG Admin services under Administration > Device Access. However those services are for management purpose only and not to allow traffic between the 2 sites.

    Create a red tunnel between the 2 sites or use the asymmetric routing workaroung and let us know if it works.

    Thanks

  • +1 in reply to Rohan Noyes

    Hi Rohan,

    Can you check to see if you can enable more features under Administration > Device Access, that is where you should be editing your device access restrictions from :)

    Emile

  • 0 in reply to Emile Belcourt

    Hi Luk & Emile,

    I was able to enable more features under Device Access for the VPN zone and can successfully browse the remote XGs from both sites. I'm pretty confident the VPN and rules are working as expected. Thanks for your assistance!

    I think I'll take a look at RED as well :)

    Thanks again!
    Rohan

  • 0 in reply to Rohan Noyes

    Hi Rohan,

    That's brilliant, glad to have helped!

    Emile

  • 0 in reply to Emile Belcourt

    Thanks again for the assistance! Just disabled the IPsec VPN and added a RED interface between the two XGs. Much, much easier!

  • 0 in reply to Rohan Noyes

    Perfect!

    Enjoy your Red-to-red configuration.