pfsense openvpn won't connect from certain cable providers ?
-
thank you, I did already change the port to the same port number as the old pfsense and it didn't work on the new but worked on the old.
-
Just to be sure : your pfSense WAN IP is a RFC1918 ? If so, don't forget to NAT the upstream ISP router also.
-
you mean in /interfaces.php?if=wan ??
Block private networks and loopback addresses ?
on the old which works everywhere its unchecked. On the new one it is checked. I think I will try that one next.
-
@pfchangs77 said in pfsense openvpn won't connect from certain cable providers ?:
Block private networks and loopback addresses ?
Block ?
I didn't say : "block".My config :
I have a WAN interface :
as you can see, my IPv4 WAN IP is 192.168.10.4, that's a RFC1918. This isn't an IPv4 that my ISP gace me, it came from the upstream ISP router, 30 cm below the my pfSense.
This means I have to add a firewall WAN rule for every incoming connection.
Here are my pfSense WAN rules :
This also means I have to add a NAT rule in my ISP router :
One for UDP port 1194 to the IPv4 WAN (192.168.10.4) to pfSense, port 1194
One for UDP port 1195 to the IPv4 WAN (192.168.10.4) to pfSense, port 1195But again, this applies only if you have an RFC1918, and you can NAT the upstream ISP router device.
No "help me" PM's please. Use the forum, the community will thank you.
Edit : and where are the logs ?? -
thank you. I will surely look into this. I can only reboot every so often since they are currently using it. I will let you know.
-
Nope, none of that. Also I unchecked "Block private networks and loopback addresses" none of that either. I didn't reboot anything either.
-
Here is a connection log of the old pfsense machine which works fine everywhere. Which I thought was setup exactly the same as the new one. Not sure what I am missing with the new pfsense. Whenever i try to connect with the new one. Just nothing seems to go through armstrong cable.
{Nov 15 17:14:15 openvpn 54016 XXX.XXX.XXX.XXX:9257 peer info: IV_VER=3.git::081bfebe:RelWithDebInfo
Nov 15 17:14:15 openvpn 54016 XXX.XXX.XXX.XXX:9257 peer info: IV_PLAT=android
Nov 15 17:14:15 openvpn 54016 XXX.XXX.XXX.XXX:9257 peer info: IV_NCP=2
Nov 15 17:14:15 openvpn 54016 XXX.XXX.XXX.XXX:9257 peer info: IV_TCPNL=1
Nov 15 17:14:15 openvpn 54016 XXX.XXX.XXX.XXX:9257 peer info: IV_PROTO=30
Nov 15 17:14:15 openvpn 54016 XXX.XXX.XXX.XXX:9257 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305:BF-CBC
Nov 15 17:14:15 openvpn 54016 XXX.XXX.XXX.XXX:9257 peer info: IV_LZO_STUB=1
Nov 15 17:14:15 openvpn 54016 XXX.XXX.XXX.XXX:9257 peer info: IV_COMP_STUB=1
Nov 15 17:14:15 openvpn 54016 XXX.XXX.XXX.XXX:9257 peer info: IV_COMP_STUBv2=1
Nov 15 17:14:15 openvpn 54016 XXX.XXX.XXX.XXX:9257 peer info: IV_GUI_VER=net.openvpn.connect.android_3.3.4-9290
Nov 15 17:14:15 openvpn 54016 XXX.XXX.XXX.XXX:9257 peer info: IV_SSO=webauth,openurl,crtext
Nov 15 17:14:15 openvpn 54016 XXX.XXX.XXX.XXX:9257 peer info: IV_BS64DL=1
Nov 15 17:14:15 openvpn 54016 XXX.XXX.XXX.XXX:9257 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1558', remote='link-mtu 1542'
Nov 15 17:14:15 openvpn 54016 XXX.XXX.XXX.XXX:9257 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #6 / time = (1700086453) 2023-11-15 17:14:13 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Nov 15 17:14:15 openvpn 54016 XXX.XXX.XXX.XXX:9257 TLS Error: incoming packet authentication failed from [AF_INET]XXX.XXX.XXX.XXX:9257
Nov 15 17:14:15 openvpn 54016 XXX.XXX.XXX.XXX:9257 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #7 / time = (1700086453) 2023-11-15 17:14:13 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Nov 15 17:14:15 openvpn 54016 XXX.XXX.XXX.XXX:9257 TLS Error: incoming packet authentication failed from [AF_INET]XXX.XXX.XXX.XXX:9257
Nov 15 17:14:15 openvpn 54016 XXX.XXX.XXX.XXX:9257 [userxxxxx] Peer Connection Initiated with [AF_INET]XXX.XXX.XXX.XXX:9257
Nov 15 17:14:15 openvpn 29325 user 'userxxxxx' authenticated
Nov 15 17:14:15 openvpn 54016 userxxxxx/XXX.XXX.XXX.XXX:9257 MULTI_sva: pool returned IPv4=193.168.2.14, IPv6=(Not enabled)
Nov 15 17:14:15 openvpn 29742 openvpn server 'ovpns1' user 'userxxxxx' address 'XXX.XXX.XXX.XXX' - connected
Nov 15 17:14:20 openvpn 31622 openvpn server 'ovpns1' user 'userxxxxx' address 'XXX.XXX.XXX.XXX' - disconnected} -
Any thoughts on the modem going bad? (Armstrong swears by it that everything is just like every other company. However they are the only one that will not connect.)
-
@Gertjan said in pfsense openvpn won't connect from certain cable providers ?:
This means I have to add a firewall WAN rule for every incoming connection.
Your not wanting to say you have to remove the rfc1918 block are you? Even if pfsense as rfc1918 wan, ie behind a nat. That block rfc1918 rule only blocks source of rfc1918.. It wouldn't stop some traffic that is coming from say 1.2.3.4 hitting your isp router, that you port forward to your pfsense wan. Unless your isp device was doing source natting and making that traffic look like it came from its rfc1918 address.
The block rfc1918 rule on the wan only needs to be removed when the "source" of the traffic would be rfc1918, it doesn't block traffic if the source is public and your pfsense wan is rfc1918. Ie pfsense behind some upstream nat router.
BTW - your pass rules, why are you using dest "this firewall" this would include all pfsense IPs, for stuff like openvpn this should really only be your pfsense wan address..
-
Thank you, I was just trying other settings thought maybe I missed something. I am just trying everything I possibly can to get this working. Any thoughts on the modem going bad? (Armstrong swears by it that everything is just like every other company. However they are the only one that will not connect.)
-
@pfchangs77 if your having an issue with someone connecting, to any service really on pfsense. First thing I would do is a sniff of the traffic (packet capture).. If pfsense never sees the traffic - doesn't matter if you have some service listening or firewall rules to block or allow, etc. Pfsense can do nothing wrong or right with the traffic if not actually being seen.
So start a packet capture under the diagnostic menu.. Send your traffic from your source client - do you see it hit pfsense? If not then there is pfsense can do with or about that traffic..
-
I did the new one everything seems fine so far.
-
@pfchangs77 well if can talk to one then your sure your getting to that one.. 1st thing to do in troubleshooting something not working, be it you can't access some service on pfsense, or some port forward through pfsense is not working is validation that pfsense is actually seeing the traffic.. Like I said if pfsense never sees the traffic - nothing you do on pfsense is going to get it to work..
-
sorry that first message I edited incorrectly. Yes no logs no nothing from armstrong. However Tmobile, verizon, spectrum and the everything else works and the list goes on just fine.
log just looks like this - (and for the record I am currently connected to the new through spectrum basically) I also did check through all the logs in the opvn and no connections not even errors where they wouldn't connect from armstrong in https://pfsense/status_logs.php?logfile=openvpn
13:49:30.356812 ARP, Request who-has xxx tell xxx length 46
13:49:30.361777 ARP, Request who-has xxx tell xxx, length 46
13:49:30.363927 ARP, Request who-has xxx tell xxx length 46
13:49:30.367753 ARP, Request who-has xxx tell xxx length 46
13:49:30.382785 ARP, Request who-has xxx tell xxx length 46
13:49:30.382854 IP xxx > xxx: ICMP echo request, id 37374, seq 24048, length 9
13:49:30.390667 IP xxx > xxx: ICMP echo reply, id 37374, seq 24048, length 9
13:49:30.401786 ARP, Request who-has xxx tell xxx, length 46 -
@pfchangs77 I think you've said several times it works from some ISPs and not other ISPs. Correct?
So either the outgoing ISP (remote end) is blocking it, or the incoming ISP is blocking it from that outgoing ISP. It can't be anything in the pfSense config if the same clients can connect from other locations. Unless you have that pfSense blocking connections for some other reason (Suricata, pfBlocker list, etc.).
-
correct, It connects fine from every single isp I have tried everything from home modems to mobile phone teathering coffee shops etc. I think I am up to 17 different providers. As of now only thing I can't get through on is armstrong cable.
And nothing like Suricata, pfBlocker. Its a stock machine basically. I thought maybe I had a setting incorrect somewhere too. I have even went as far as trying different routers and taking them over. However there is a old pfsense machine on (spectrum) that will let me connect from armstrong and thats why I was thinking its a setting.
However the new pfsense machine is on armstrong to but I can connect fine from the other 17 different providers, but just not any device with another armstrong connection. Maybe something is conflicting there?
And yes I agree I think it something that armstrong is blocking with the out going to >> the new pfsense machine. However armstrong isn't blocking the out going >> old pfsense machine on spectrum because I can connect to it.
-
@pfchangs77 again a 10 second sniff would validate that pfsense is either seeing it or not seeing it.. if not seeing then you no for fact that something upstream is blocking it.. Either at the sender source, or something in your isp above pfsense, or something between.. It would take all of like 30 seconds tops to validate if pfsense is seeing it or not..
-
With the sniff I provided above that didn't help with anything? (I am not sure exactly what you are looking for with the sniff.) I have never had any issues with any other pfsense I setup before. I apologize for my ignorance on this one.
-
@pfchangs77 said in pfsense openvpn won't connect from certain cable providers ?:
I am not sure exactly what you are looking for with the sniff.
The sniff test will proof that traffic reaches pfSense.
You'll be looking the packets coming in, and check for the presence of the IP your are using with the OpenVPN client.Example : you have a OpenVPN UDP port 1195 open on the WAN. You have a firewall rule on WAN with these settings :
- WAN
- Using protocol UDP
- on port 1195.
Start the sniff.
Now, start the OpenVPN client on a device, also connected to WAN (== the Internet which means no Wifi active on that device).
If the sniffer starts to show incoming packets, and the source IP of these packets have the IP of the device you are using with the Openclient you know now that traffic reaches from this device reaches pfSense.
Which means the traffic reaches the OpenVPN server.If no traffic comes in, locate the WAN cable on pfSEnse, and then follow this cable upstream. You might be needing your car to find the device where your traffic got stuck.
-
gottcha thank you, I provided the incorrect sniff packet. I will do that then go from there. thank you. And follow up from there.
Also one last thought, is there any tool I can use from the other end? when I am at the persons house that has the armstrong cable?
