Question regarding the internal "$INTERFACE net" alias & pf syntax translation
-
OpenVPN is configured as a remote access server in tunneling mode. I have assigned subnet 192.168.4.0/24 to it. The alias OPENVPNsubnet contains 192.168.4.0/24.
-
Sorry. I see you had already stated that. You're not testing using an already-established state are you?
Clearing states doesn't make it function as expected?
-
I have tried rebooting the firewall, resetting the states, reloading the firewall rules several times, rebooting my iphone, but no luck. Now I cant access anything from the openvpn client anymore :-[
Is it absolutly necessary to assign an OPTx interface to ovpns1()? I have just tried deleting the interface and stick with this very basic setup according to: https://doc.pfsense.org/index.php/OpenVPN_Remote_Access_Server
The only difference is that I enabled
[code]Allocate only one IP per client (topology subnet), rather than an isolated subnet per client (topology net30).
The OpenVPN firewall rule tab contains an any to any allow rule. But now the firewall log shows many packets hitting the "Default deny rule IPv4" coming from the openvpn client.
[EDIT] Just found the culprit, there was a mistake in the any to any rule… let's call it a day... :-\
-
Are you using an OpenVPN assigned interface? If so, rules on the OpenVPN tab are processed first. When I use assigned interfaces I typically delete all the rules on the OpenVPN tab.
The attached rules do what I expect. These are on the OpenVPN tab. 172.29.64.0/24 is my Remote Access tunnel network - topology subnet.
![Screen Shot 2015-03-08 at 2.08.21 PM.png](/public/imported_attachments/1/Screen Shot 2015-03-08 at 2.08.21 PM.png)
![Screen Shot 2015-03-08 at 2.08.21 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2015-03-08 at 2.08.21 PM.png_thumb) -
If I use an explicit block for the destination "The firewall" and HTTPs - access is denied properly. However I just dont understand why my "catch-and-deny-all-to-local-network" rule is not rejecting the access. See my point?
-
It depends on what you want to do. For instance, if you want to NAT on OpenVPN addresses, then you have to have an assigned interface.
Assigned interfaces give you a lot more granular control over who can do what. Rules on the OpenVPN tab apply to all OpenVPN instances and are processed before rules on assigned interface tabs. So, In general, if you use both the rules on the OpenVPN tab cannot match the traffic in question or the interface rule is never processed.
You're missing something. This blocks the webconfig on 192.168.223.1:8883 the same as the This firewall rule.
![Screen Shot 2015-03-08 at 2.20.09 PM.png](/public/imported_attachments/1/Screen Shot 2015-03-08 at 2.20.09 PM.png)
![Screen Shot 2015-03-08 at 2.20.09 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2015-03-08 at 2.20.09 PM.png_thumb) -
typo in your alias. 192.186, not 192.168. Slow down.
(THIS is why we always insist on screen shots instead of simply a description of what users think they've done.)
-
And always make your DNS rules TCP/UDP. It's usually UDP but sometimes TCP (large responses, etc. DNSSEC triggers a lot more DNS over TCP.)
-
awesome!! thanks a lot, that was really driving me nuts. :o :)
-
This however get's translated into:
Code:block return in log quick on $VNET inet from 192.168.2.1/24 to $any_local_network tracker 1422306076 label "USER_RULE"
Is this a bug or something I have missed? Thanks for clarifying.
It is a feature ;)
I don't think it effects the actual set of addresses that PF ends up matching for the rule, but it should be made neater and consistent with the way LANnet and WANnet are handled.
This does it: https://github.com/pfsense/pfsense/pull/1564