IPSec not working between SG1100s
-
@stephenw10 I decided to perform a factory reset on sg1100 and try to do the IPSec from scratch - I can confirm that this does not solve the issue at all. I was hoping WiFi calling would be working, but nada. Out of desperation, I have plugged an old PC that had pfsense installed and IPSec/wifi calling are working flawlessly.
Not sure what could be the issue, perhaps default sg1100's VLANs for whatever reason?
-
So the IPSec tunnels still don't connect? Or just that you are routing wifi calling over that and it fails?
-
@stephenw10 Neither. IPSec still don't connect unless I change ports to 600 on sg1000, phones are trying to connect to career's vpn and they do use port 500 with status SINGLE:NO_TRAFFIC. Disabling wifi-calling on the phones and then freeing port 500 from states does not change anything - it still doesn't work.
-
Hmm, the only thing pfSense does that could be affecting anything is the static source ports for outbound port 500. That is the default setting though so would apply equally to an 1100 and a CE install. Also it would only be an issue if somehow the wifi calling was holding open a port 500 state to the remote tunnel IP which I wouldn't expect it to ever connect to.
Reviewing; did you see port 500 or 4500 traffic arriving from the remote side of the tunnel?
Are those 1100s connected with public IPs directly or behind some other router?
Steve
-
Currently, I've disabled any IPSec (both remote and site to site) and will focus on WiFi-Calling as it seems to be the most independent service - technically if WiFi-Calling would work, the rest will follow.
As you've mentioned, states are created but no actual connection is made (I guess). There are currently two Apple devices that attempt to connect to the career's port 500, both of them fail.
And no, when I had site2site and/or remote access enabled, despite making the connection, I have never seen incoming connections being allocated in the states table. Oddly enough, if IPSec was working site2site, RemoteAccess would never work and just throw configuration error - I suppose anything other than UDP 500 will break stuff in most cases.
I did notice, that during the RemoteAccess connection, instead of instantly throwing a configuration error / refusing connection it simply timed out, again, never appeared in the states table.
Both SG1100s are connected directly to an intermediate device (modem in this case) in a bridge mode. There are no double-nat occurring or subnet collisions with ISPs - we have even tried 192.168.x subnet. I did narrow the issue to my unit though.
P.S. I was just about to send this reply when I noticed 4500 incoming in States table, but with no real traffic - it disappeared fairly quickly anyway. Random botnet I guess. The apple devices are still retrying to connect to the career's IPsec service with no luck.
-
Hmm, OK. You can see the wifi calling devices creating outbound states there but there is no reply traffic at all. At least none that matched those states.
When you have multiple devices connecting the same external IP and outbound NAT is using static source ports you can see a conflict as the WAN side state is identical. That's normally not an issue since the connection switches to UDP/4500 once it's established.
I would try disabling the static source port NAT rule for port 500 and see if that makes any difference. Most recent VPN devices can cope with random source ports anyway.I would run a packet capture at both ends of the site to site tunnel to be sure you are seeing any port 500 traffic arrive at all.
Normally only traffic from configured end points is allowed but if you have a remote access tunnel setup that obviously allows traffic from any remote IP.
Steve
-
@stephenw10 I can confirm 4500 port would work, since I have tried using my work VPN today, which does use IPSec as well. Turns out 4500 was never the issue at all.
Static Port Mapping has been disabled on the outbound NAT and now outgoing connections are used randomized ports. This however still doesn't fix the issue, so there is still NO_TRAFFIC:SINGLE or SINGLE:NO_TRAFFIC on 500 port equivalents.
-
If you Upgrade from a older Version to 21.05.1 it is possible to run into a Crypto Bug.
Shutdown your Netgate, unplug the Power for 1 minut and start up again. Try the VPN Tunnel now.
-
I have tried doing so and then even factory resetting again - nothing has changed. I've plugged the HP-pfsense back and works like a charm. Does that mean it's time for RMA?
-
That crypto hardware issue would not effect IPSec, that device is only used to access authenticate the repos.
Even if you were seeing an issue with the safexcel hardware crypto, which IPSec can use, it would not prevent the tunnel connecting at all.When you are swapping back the other pfSense device are you doing that at both ends? Or is one 1100 working as expected?
Steve
-
@stephenw10 the remote sg1100 is working as expected. It’s just mine unit that seems to not be working.
-
The only thing that could present a difference here is the hardware crypto in the safexcel driver. But you said you tried using a cipher that does not effect (blowfish) so it can't be that directly.
So I'm left trying to think of something you might have had set in the old device that's somehow incompatible with the SG-1100. I can't see what that could be though.
The fact setting the tunnel to use ports 600/4600 allowed it to come up implies something in the path blocking the standard ports. The crypto hardware doesn't care what ports are in use for example.
It really 'feels' like the upstream device trying to do something clever with IPSec traffic.
Are we able to review the config you are importing to the 1100? If you open a ticket with us and reference this thread the guys will make sure I see it.
It's hard to see how this could be a hardware issue. If we swapped it out I would expect another device to do exactly the same thing given the same config.
Steve
