Cisco AnyConnect VPN behind a pfSense 2.4.5
-
I don't even think it takes 40 seconds on my work laptop - and its old POS ;)
Just looked through my log on my client 29 seconds to connect..
I suggest you get to with your IT dept.. But there is nothing special with you creating a vpn.
Pfsense doesn't know packet A from packet B for what it is.. Its udp or tcp, and it passes it on and changes the ports for the NAT.
Are you doing something odd with scrub, or mss... I can tell you I have pfsense - and have ZERO issues maintaining a connection with anyconnect.. I show my current connection being up for 12 days +
Its not doing any static port nat, etc.
Are you running IPS that could be seeing something odd in the traffic and blocking it?
Love to help you - but it sure is not something wrong in pfsense.. With how many people are working from home, and any connect is a very common work thing.. I would think if there was something wrong the boards would be on fire..
I can not even think of anything you could turn on to cause the problem.. Other than messing with your mtu, or scrubbing, etc..
-
The biggest difference between pfSense and most soho style routers is that pfSense will randomise the source port of outgoing traffic by default.
You said you tried using different outbound NAT modes but did you actually set a static port rule for your client device?
I could imagine the remote side starts to connect and then rejects it based on an unexpected source port and has to fall back to some other mode or something similar.
Steve
-
That could be an issue sure... But this is exactly the reason I posted my states, where it shows the source port was changed.
And not sure what soho routers your looking at ;) But everyone I have seen does source port changing as well.. This is how napt works.. Its possible his doesn't do that? But I am not aware of cisco anyconnect caring.
If that was the case - what are the odds that the source port would end up the same after the nat.. Roughly 65k to 1 ;) I just don't see him ever connecting if that was the case..
His mention of dead peer detection.. I take it they are using DTLS then vs ipsec for their connection.. On the client you can see for sure under the stats tab .. For example mine is using IKEv2/IPsec NAT-T
You really need to get with your IT if your having issues maintaining or getting a connection.. If this was an issue with pfsense, the boards would be lit up with issues..
-
Mmm. I've never looked at an Anyconnect server but I imagine it has some configurable options.
Just from a high level when you see soho device X works fine and pfSense does not it's usually because of source port randomization.
And usually some crappy app that has been written assuming static ports. I do not expect Anyconnect to fall into that category though!
Steve
-
DTLS can be tricky - there are 2 tunnels that are brought up.. the normal TLS one which is control, and then the actual data tunnel which is just UDP..
If he is having connectivity issues, this can be problematic for sure. The whole point of the dead peer configuration..
Without both sides - knowing how its all configured.. etc.. It can be troublesome to troubleshoot what could be the problem. Which is why he really should get with his IT dept.. They have all the logs on their end, they can see the logs from his client (even if he has to send them via dart) etc..
-
@johnpoz cheers for the help, it's appreciated..
Here's a packet dump and a screenshot. The host x.x.x.76.443 is the firewall and its a SSL VPN on port 443 as you can see the connection comes up and then resets ~1min and then stays connected.
Re How exactly are you sure its connecting to the same peer I can see the same fqdn and IP address in the packet dump.. I do take your point about blips on networks but 10/10 times its reconnecting after ~1min and then stays connected for up to the VPN limit of 15hours
I tried to post the packet capture but this site thinks it's spam?
Thanks
Alex
-
@johnpoz DTLS can be tricky - there are 2 tunnels that are brought up.. the normal TLS one which is control, and then the actual data tunnel which is just UDP..
Hang on, i'll BRB
-
Yep, threw in an ip any any rule for a test!!
Yep, the port 443 UDP traffic, because I can't get a packet capture from the work laptop I couldn't see the 0 packet length
and our company documents say SSL port 443 so I went with TCP and because it worked but then re-connected / failed back to TCP..21:23:41.717625 IP 192.168.30.40.53444 > x.x.x.x.443: tcp 37 21:23:41.734610 IP x.x.x.x.443 > 192.168.30.40.53444: tcp 37 21:23:41.737181 IP 192.168.30.40.53444 > x.x.x.x.443: tcp 0 21:23:42.198962 IP 192.168.30.40.55546 > x.x.x.x.443: **UDP**, length 102 21:23:43.723197 IP 192.168.30.40.55546 > x.x.x.x.443: **UDP**, length 100 21:23:43.723234 IP 192.168.30.40.55546 > x.x.x.x.443: **UDP**, length 100 21:23:44.365881 IP 192.168.30.40.55546 > x.x.x.x.443: **UDP**, length 134Thank you
-
@alex-the-firewall said in Cisco AnyConnect VPN behind a pfSense 2.4.5:
so I went with TCP
Meaning what? You altered the default any any rules? When you were sniffing you only did tcp? You made no mention of alerting the default lan rule which is any any..
I take it your working now? Or you still not coming up on UDP? And falling back to tcp?
You sure your IT dept has udp open on their end? I have seen it happen ;)
Your IT dept would of seen that right away if they bothered to look into it at all..
-
@johnpoz Hello and thanks
Yes I only had TCP port 443 outbound from my work VLAN and after adding UDP all is better. I'll VPN into work and update that wiki page
