OPNsense Forum
English Forums => General Discussion => Topic started by: KillerCow on June 15, 2020, 12:48:58 pm
-
Hi there
I'm running an opnsense system (v20.1.7) primarily as a VPN Gateway. Currently there is a problem with two IPSEC Tunnels, one being IKEv1 and the other IKEv2, both with one phase 2 entry. Both remote ends look like being Cisco ASA Systems, so I think it might be the same rootcause.
Looking at the IKEv2 Tunnel, it is up an running. I can ping a client system at the other end just fine, but the other side can't ping me. They told me, they see the pakets entering the tunnel an leaving their WAN into my direction (they sent screenshots of a log of some kind). But I don't see any of those pakets reaching my WAN interface using tcpdump (on the opnsense), nor are there any dropped pakets logged in fw-log.
I do see incoming isakmp pakets every 10s (keep-alive mechanism?) and outgoing replies from my side. I also see my echo requests going out and the incoming replies as encrypted pakets on WAN and unencrypted on IPSEC.
Right now I suspect some configuration issue at their end, because no pakets from connections initiated at the remote side are reaching my WAN. The remote side asked me to disable NAT-T in case this has something to do with it, with no success (I thought NAT-T is an automatic feature with v2 and can't be enabled/disabled manually?).
At one ocassion, they had their ping running, which failed all the time. But the second I started my ping, their ping started to work. This happened one time but now we are back at the beginning.
Any ideas? Am I right in assuming the problem is located at there end or can a misconfiguration at my end be the problem?
Many thanks in advance :)
PS: if there are more details needed, please specify.
-
Problem solved.
TLDR: Turned out to be a issue with the cloud provider the opnsense is hosted at, which resulted in blocked ESP pakets.
They have a simplistic firewall that can be enabled which I used at the beginning of my experiments with this environment, but which I disabled some time ago. It looks like this firewall was active again without showing as being active in their API. My old rules where preserved which allowed UDP 500 and 4500 in, but not ESP. This explains, why their pakets came in after I sent pakets in their direction.
The other tunnels must have been affected also, but we didn't noticed this, as we are sending traffic to the remote peers on a regular basis.