Client can connect but access LAN resources

[ega]

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.

[Derelict]

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?

[ega]

@Derelict:

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.

[gollo]

@Derelict:

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.

[gollo]

@Derelict:

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

[gollo]

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.

[Derelict]

@ega:

@Derelict:

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.

[Derelict]

@gollo:

@Derelict:

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?

[ega]

@Derelict:

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.

[smithjoe1]

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.

[Clouseau]

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!