Client can connect but access LAN resources
-
Huh?
Shitty advice. There's nothing wrong with UDP OpenVPN. In fact it's recommended.
-
I had the same issue, and somewhere in openvpn's forum, somebody posted that some routers arent "intelligent" to send UDP backward traffic, so the recomendation was work with TCP, because TCP doesnt have this issue.
Dont know if thats true, and if this is crazy to do vpn over tcp, but it work for me.
I will try to work again with udp, and post the result.
c yap!
-
@ega:
Are you running on UDP or TCP protocol? I had a similar problem with UDP behind a NAT, when I get a public IP UDP works fine, behind a NAT don't work.
Then set openvpn protocol to TCP, export users again and works fine.
It does it with both UDP and TCP options.
The fact that pfsense can ping the client IP tells me that the tunnel piece is working. Just that something on the pfsense side isn't passing traffic.
-
post screenshots of the openvpn configuration + firewall rules on LAN & openvpn-tab
As requested
-
Why tap not tun?
-
Why tap not tun?
One of the tests in order to try and get it operational. I've since changed it back to tun.
-
That's not a test, it's guessy-guessy-clicky-clicky lord knows what else you've clicked.
I suggest you delete everything and start over using this:
https://doc.pfsense.org/index.php/OpenVPN_Remote_Access_Server
-
I think that the Lan rule is wrong
Modify it and put this to try
Action pass
Protocol tcp/udp (after you can change for one or the other, just for tests)
Destination port range 1194
Destination lan address ( here you have the tunnel address)And try again
-
Or… do the tutorial as derelict says ;D
Btw derelict, I could run ovpn on udp behind nat, dont know what happened before that I couldnt.
-
I think that the Lan rule is wrong
That LAN rule is completely unnecessary because the same traffic will be passed by the following any any any rule. Looks like it's being used for policy logging, which is fine.
@OP You are issuing a new client config every time you make a server change (like tap to tun, tcp to udp, etc)
@OP What's the local IP network at the client site that's having trouble?
-
That LAN rule is completely unnecessary because the same traffic will be passed by the following any any any rule. Looks like it's being used for policy logging, which is fine.
I think that the following any any rule doesnt cover ovpn traffic, because ovpn traffic doesnt has lan net as source.
-
That's not a test, it's guessy-guessy-clicky-clicky lord knows what else you've clicked.
I suggest you delete everything and start over using this:
https://doc.pfsense.org/index.php/OpenVPN_Remote_Access_Server
Last I checked that is what testing was: make a change…. TEST.... Works? Leave setting. Doesn't work? Put it back to recommended default.
-
I think that the Lan rule is wrong
That LAN rule is completely unnecessary because the same traffic will be passed by the following any any any rule. Looks like it's being used for policy logging, which is fine.
@OP You are issuing a new client config every time you make a server change (like tap to tun, tcp to udp, etc)
@OP What's the local IP network at the client site that's having trouble?
Yes, new config every time.
Client gets 172.16.17.2 and pfsense gets 172.16.17.1. From LAN server I can ping 172.16.17.1
-
Well, I'm not sure what changed but I rebooted earlier this morning and now traffic is passing.
Thanks all for the input. It is appreciated.
-
@ega:
That LAN rule is completely unnecessary because the same traffic will be passed by the following any any any rule. Looks like it's being used for policy logging, which is fine.
I think that the following any any rule doesnt cover ovpn traffic, because ovpn traffic doesnt has lan net as source.
Then you have a fundamental misunderstanding about firewall rules and how they work in pfSense.
-
I think that the Lan rule is wrong
That LAN rule is completely unnecessary because the same traffic will be passed by the following any any any rule. Looks like it's being used for policy logging, which is fine.
@OP You are issuing a new client config every time you make a server change (like tap to tun, tcp to udp, etc)
@OP What's the local IP network at the client site that's having trouble?
Yes, new config every time.
Client gets 172.16.17.2 and pfsense gets 172.16.17.1. From LAN server I can ping 172.16.17.1
No. What is the LAN IP scheme on the network where the client is connecting from? Is it also 192.168.0.0/24?
-
Then you have a fundamental misunderstanding about firewall rules and how they work in pfSense.
I'm agree with you, I'm thinking that, because that rule on lan interface, was generated by the wizard
I've disabled it and still had VPN access.
-
If this is a windows client, I've had the same problem when the OpenVPN tunnel is opened without administrator permissions and it doesn't normally ask to elevate its permissions and it looks like it connects without any issues, but the new routes fail to work correctly in the manner you had described. Setting the client to always require administrator privileges to run fixed it for me.
-
When pfSense moved to StrongSwan from Racoon, our mobile ipsec went dead for ever. Site to Site works. After that I moved out from pfSense ipsec and took closen look to OpenVPN. I had problems with udp protocol - it did just not work, but after I changed to use TCP - no problems and it works like charm.
So do everything with TCP protocol. With udp I could establish conection and even saw trafic coming from client to LAN, but all trafic from LAN back to client did not work. I had automatic rules done allowing any to all…. => change to TCP and all went right!
