OpenVPN behind the router
-
Hi.
Purpose is authenticate the openvpn clients.
I run pfsense in the XEN environment, WAN if is in the private block.
In the firewall, font of the pfsense box, I NAT the traffic from outside towards the pfsense.
So the picture is like:INTERNET <> FIREWALL <> (192.168.1.0/24) <> PFSENSE <> ANOTHER LAN(s)
From internet. SSH is working fine, I can see that traffic is accepted:
May 18 11:26:29 pfSense filterlog: 76,,,1526636721,xn0,match,pass,in,4,0x0,,121,21156,0,DF,6,tcp,52,193.123.123.123,192.168.1.10,49386,22,0,S,994952218,,64240,,mss;nop;wscale;nop;nop;sackOK
Now when I try to connect to pfsense with openVPN, regardless that I have allowed everything in the filter policy, I get block:
May 18 11:28:08 pfSense filterlog: 5,,,1000000103,xn0,match,block,in,4,0x0,,60,9389,0,DF,17,udp,70,85.76.83.183,192.168.1.10,43232,1194,50
If I disable the firewall (Disable all packet filtering) openvpn authentication works just fine.
Any ideas ?
/ br, pete
-
Please, post the WAN rule for OpenVPN.
-
Since this is LAB env. I have opened basically everything.
And as mentioned, ssh works. Wondering is this somehow UDP related, so could there be some general UDP drop from WAN.br, pete
-
Do you have "Block private networks and loopback addresses" unchecked on your WAN interface?
OpenVPN instance(s) server or client on your Pfsense box?
-
Do you have "Block private networks and loopback addresses" unchecked on your WAN interface?
OpenVPN instance(s) server or client on your Pfsense box?That won't matter since the source address is presumably public: 85.76.83.183
Unless that is actually a bogon. But in that case it would be blocked by the bogon rule, not the default deny.
OP is obviously not passing the OpenVPN traffic. As was already asked, post the OpenVPN rule on that WAN interface.
-
That won't matter since the source address is presumably public: 85.76.83.183
Not according to his graph..
INTERNET <> FIREWALL <> (192.168.1.0/24) <> PFSENSE <> ANOTHER LAN(s)
Maybe I read wrong..??
-
Derelict is right, in the firts post the src address is 85.76.83.183 (from Finnish mobile ISP pool) - and my mistake, the original post was innacurate.
So the pfsense sees the original public src.
However the "Block private networks and loopback addresses" is unchecked.
Is there a way to see the ruleset from cli to post it here.
pfctl -sr does not return anything.
/ br, pete
-
That won't matter since the source address is presumably public: 85.76.83.183
Not according to his graph..
INTERNET <> FIREWALL <> (192.168.1.0/24) <> PFSENSE <> ANOTHER LAN(s)
Maybe I read wrong..??May 18 11:28:08 pfSense filterlog: 5,,,1000000103,xn0,match,block,in,4,0x0,,60,9389,0,DF,17,udp,70,85.76.83.183,192.168.1.10,43232,1194,50
That is the source address that was blocked. It is not RFC1918. It was blocked by the default deny rule, not the RFC1918 block rule.
-
@nikkope@gmail.com:
Derelict is right, in the firts post the src address is 85.76.83.183 (from Finnish mobile ISP pool) - and my mistake, the original post was innacurate.
So the pfsense sees the original public src.
However the "Block private networks and loopback addresses" is unchecked.
Is there a way to see the ruleset from cli to post it here.
pfctl -sr does not return anything.
/ br, pete
pfctl -sr should definitely show something. Is your ruleset even loading? Are there any alerts in the upper-right of the GUI?
What does this say?
pfctl -nf /tmp/rules.debug
What is in /tmp/rules.debug?
-
I did found the problem.
Thank You all.
The problem was that I had I fw rule that prevented the ruleset to load.
Good point from Derelict, pfctl should definitely show the ruleset.
The problematic row was:
There were error(s) loading the rules: /tmp/rules.debug:140: unknown protocol udp4 - The line in question reads [140]: pass in quick on $WAN reply-to ( xn0 192.168.1.1 ) inet proto udp4 from any to 192.168.1.10 tracker 1526637072 keep state label "USER_RULE: OpenVPN wizard"
I did found this by reloading the rules and checking the reload status. After changing that and reloading everything works as should.
Thanks again for all !
/ br, pete
-
That is from an issue with the openvpn wizard. Already fixed in 2.4.3_1 and 2.3.5_2
