- Products
- Learn
- Local User Groups
- Partners
-
More
Celebrate the New Year
With CheckMates!
Value of Security
Vendor Self-Awareness
Join Us for CPX 360
23-24 February 2021
Important certificate update to CloudGuard Controller, CME,
and Azure HA Security Gateways
How to Remediate Endpoint & VPN
Issues (in versions E81.10 or earlier)
Mobile Security
Buyer's Guide Out Now
Important! R80 and R80.10
End Of Support around the corner (May 2021)
Hi,
I have a cluster with more external interfaces, two interfaces are Internet peers and third external interface is connected to telecom MPLS service. I am trying do do S2S VPN setup from MPLS interface towards the remote Sophos Cyberoam device. Anyway, my tunnel is not coming UP although I checked all VPN parameters, I am suspecting it has something to do with this strange IKE behavior. Other end device is Sophos Cyberoam device and it reports error message that we are using wrong PeerID, it sees our main Internet interface address as our PeerID instead of our MPLS interface address.
Yes, see scenario 2 of this SK: sk108600: VPN Site-to-Site with 3rd party
Need some basic information like:
Also, I don't understand what you mean by "more external interfaces."
Please describe your configuration more precisely.
Hello Phoneboy,
Here is my version: R80.40, OS build 294, take 78 on both cluster members.
I do not have exact information about the other end of VPN, it is a Sophos Cyberoam device, I will try to get more detail information since it is a device from other organization.
Link Selection is left as default, I am sending screenshot with my settings. I have declared other end VPN gateway as interoperable device and it has the same Link selection settings.
I have three interfaces which are declared as external in my Network topology, two of them have public addresses and this third interface has private address and it is used for connecting to other organization over the MPLS VPN service. So, we are trying to establish S2S VPN over this third external interface. Besides these external interfaces, I have several interfaces declared as internal.
do a tcpdump/cppcap on your third external interface (MPLS) and have a look at the source and destination IPs of your IPSEC packets.
I suggest to change the link selection to "IP address of chosen interface" in the source IP address settings. With this change the IP address of your MPLS interface should be use for connection to the Sophos device. The Sophos device should use your MPLS IP address as destination for the IPSEC tunnel.
Wolfgang
Hi @Wolfgang
I just have check it with tcpdump and everything is fine, I am sending and receiving ISAKMP IKE packets with correct source/destination address.
I am editing this reply, so to be more precise, src/dst IP address of our IKE message is fine, but inside the IKE MM5 message we have our PeerID set to wrong address, so instead of our MPLS interface, we have our Main Public Internet address set as a PeerID.
I see IKE Phase 1 is establishing, something is wrong with the Phase 2. I will try to verify the networks with the remote end administrator.
I am editing this reply, even Phase 1 is not establishing since PeerID address is set to wrong address.
You need to find out precisely how the Sophos is configured as far as what networks (and their subnet masks) it is expecting from your gateway during the Phase 2 negotiation, as well as precisely what networks (and their subnet masks) the Sophos is providing to you, and then the per-community VPN domains settings to match the Sophos exactly as shown here (this is a new feature in R80.40):
Thanks for your advice. I have now arranged with remote administrator to do first setup with just one network on each side and I have configured VPN domains accordingly. I believe the problem is because remote device sees my public IP address as Peer ID instead of my private IP address from interface towards MPLS link.
Right, you need to change VPN Link Selection from "Always use this address" to "Calculate IP based on network topology" to ensure your firewall uses the correct source address. Making this change should not disrupt your existing Internet VPNs but you may want to make the change outside regular business hours, and immediately reset all Site-To-Site VPNs with vpn tu (option 0) to ensure they will come back properly with the new setting.
Hi @Timothy_Hall ,
I have done it just as you described, followed by resetting all VPNS, but my problematic VPN is still down. I have noticed one interesting thing, I have declared 192.168.70.21/32 as my local network, as you described above, but when I list the tunnels with the vpn tu tlist command, it is showing the complete subnet 192.168.70.0/24 as a local TS, which is very strange, here it is:
[Expert@CP2:0]# vpn tu tlist
+-----------------------------------------+-----------------------+---------------------+
| Peer: xx.xx.xx.x - VPN_GW_P1 | MSA: ffffc900a1e14128 | i: 0 ref: 1 |
| Methods: ESP Tunnel PFS AES-128 SHA1 g..| | i: 1 ref: 1 |
| My TS: 192.168.70.0/24 | | |
| Peer TS: x.x.x.x | | |
| MSPI: 8000ad (i: 1, p: 0) | No outbound SA | |
+-----------------------------------------+-----------------------+---------------------+
We have tried everything, trying all possible settings from the Link Selection menu, we have tried different option from both Global Link Selection menu and Link Selection menu from the Interoperable device but without any success. We have performed IKE debug for all scenarios and PeerID is always set to our Internet address instead of our MPLS interface. We see from our IKE debug that once remote end detect wrong PeerID address, the negotiation immediately fails.
One more fact to know, we are using L2 MPLS service, so remote Sophos Cyberoam device IP address is in the same subnet as our MPLS interface address. Is there any option to set our PeerID to address of outgoing interface during the Phase1 IKE negotiation.
Yes, see scenario 2 of this SK: sk108600: VPN Site-to-Site with 3rd party
Hi @Timothy_Hall ,
excellent, this was very valuable information for us, after appending SenderIP into gateways registry our tunnel went UP. Seems that remote Cyberoam device is checking value of this field in order to do key install. Thank you very much for your help.
About CheckMates
Learn Check Point
Advanced Learning
WELCOME TO THE FUTURE OF CYBER SECURITY