Messages

Suggestion for firewall feature:

IP addition:
This will add the source IP to a specific alias (choosable in dropdown), once a match is found in the rule.
The time the IP will remain in the alias, should also be able to be defined, once the IP is expired, its auto-deleted from alias.
However, if IP is already in alias, nothing happens.

What this can be used for (2 examples):
1: Banning port scanners. This by defining rules for all non-open ports, and then directing the firewall to add the IP to alias.
Example:
Source:banned to Any DROP
Source:Any to port 1-79 DROP (add ip to alias banned expiry=30min)
Source:Any to port 80 PASS

anyone that sends any packet to 1-79 will not be able to connect to port 80 for the next 30 minutes.

2: Implementing port knocking. This by defining a alias for every port you want to be part of your "sequence", and then creating rules to define this "chain".
For example:
source:Any to port 35 DROP (add ip to alias step2 expiry=10sec)
source:step2 to port 65 DROP (add ip to alias step3 expiry=10sec)
source:step3 to port 96 DROP (add ip to alias step4 expiry=1hour)
source:step4 to port 22 PASS

Connecting to 35, 65 and 96 in sequence, even if all packets are dropped, will then open port 22 for you.

I would suggest adding the following settings to the OpenVPN setup page, BEFORE advanced section is removed. Some VPN providers require these to work:

1: checkbox for "persist-tun" (Keep tun interface up even when connection is down)
2: checkbox for "persist-key" (Keep key intact between connections)
3: checkbox for "auth-retry nointeract" (Retry automatically on authentication error) (The reason this is required, is that some VPN providers do have a "device limit", for example 1 device per account, and if you suddely lose connection, it will take some time for the "device limit" to reset, and if OpenVPN shuts down due to AUTH_FAIL, then you have to manually interact each time OpenVPN loses connection, but if it retry, it will retry until device limit is auto-resetted.)
4: Key direction for Static key (dropdown)
5: IP and mask setting (2 textboxes) - correspond to ifconfig <IP> <MASK> - required for static-IP VPNs
6: Setting for remote-cert-tls (dropdown)
8: Checkbox for "mute replay warnings"
9: textbox for "reneg-sec"
10: textbox for "replay-window"

Actually, pfsense have had this feature for years, to send the Captive Portal usernames to the proxy via IP adress, so ACL rules could be gated by username or voucher code.

https://github.com/pfsense/pfsense-packages/blob/master/config/squid3/34/check_ip.php

https://github.com/pfsense/pfsense-packages/blob/master/config/squid3/34/squid.inc#L1867

Squid also has support for checking the MAC adress aswell, as long as the squid is the "first router closest to client".

A nice feature would actually be to add this feature to opnsense, with both IP and MAC checking.

An additional feature that could be added, is that if BOTH captive portal and squid is enabled for a interface, the original captive portal handling could be disabled, and instead have a custom "Access Denied" page in squid which contains the captive portal login form.

The gating of users is then done by squid itself. The only thing the captive portal script is doing then, is adding firewall rules for other ports than the proxy. This could also be added to captive portal, an ability to specify which other ports an specific user should have access to, except for the 80 and 443 and 53 ports.
(basically, users always have full access to the proxy, its the proxy itself which then denies users to locations where they are not authorized when they are not logged in)


I guess Sensei has a plugin to squid, thus sensei could act on that auth info?
Or sensei could fetch the information in the same way as squid does in pfsense.

Because I have set up a server that handles dynamic domain names (users in a educational facility, like user1.pupils.school.tld), so I cannot statically define them anywhere.
And I want these dynamic domain names to be reachable from inside the firewall aswell.

So by pointing the external IP to the "inside IP" it should work, but apparently it does not.
Why not?

If a packet comes in the LAN interface:

Source IP: 192.168.1.95
Source port: 42357

Destination IP: [WAN IP]
Destination Port: 80

And the NAT rewrites this to the following:

Source IP: 192.168.1.95
Source port: 42357

Destination IP: 192.168.1.10
Destination Port: 80

Why does it not work? Any that have a technical explanation?

I have a network with a NAT rule as follows:

WAN any:any "WAN Adress":80 redirect to 192.168.1.10 port 80

This works wonderfully from outside, but it doesn't work from the inside (Typing the WAN adress on the inside of the network instead lands you in the administrative interface of the firewall).

Now I want, that if I, from inside the network, type the external IP of the network, this packet should be rewritten to remain in the network instead.

So I create a rule as follows:

LAN any:any "WAN Adress":80 redirect to 192.168.1.10 port 80

The idea is that if you are inside the 192.168.1.* network (coming from the LAN interface), and write the WAN adress in the adress bar, you should land in the 192.168.1.10 server (like you visited the server from outside). But this doesn't work.

The idea is that automatically resetting interfaces are not going to help anyways.

If an administrator did switch out a network interface, the administrator will also be present to do the interface reassignment manually.

Best is to not touch anything, but in some cases a interface might change name after a reboot - but a automatic reset is not going to fix that anyways.

I think the following logic would be best to recover from a "bad situation": Store the physical MAC of each interface, and also its name (eg em0, re0 etc)

Upon mismatch, do the following:

1: First, match every interface found by hardware MAC to its configured interface that is stored by MAC. This will catch any cases where a interface just changes name, from lets say re0 to re1.
If this interface has VLAN assignments, automatically rename them too.

2: For any interfaces left, match by exact driver name, so any interface configured as re2 will be matched to re2.

3: For any interfaces left here, match driver name against any interface with same driver - in the same order.
So if there is re4, re5 and em1 configured, and phy re6, re7, em0 - then do the following replacements:
re4 --> re6
re5 --> re7
em1 --> em0

4: Assign any leftover hardware interfaces to any leftover firewall interface, same order as enumerated and configured.

5: Any interface left as this point should be left UNTOUCHED, even if theres no hardware interface left.
Don't delete interfaces because they don't exist in real machine, just leave them there in the GUI but with a "None" assignment, so the user can itself reassign them. (But still keep all firewall rules and configs - just that these firewall rules and configs would then be dormant due to the non-existing interface - so when that interface is replaced or fixed, the interface can be reassigned without any loss of data)


Those 5 steps is going to get the best bet to recover from a bad situation.


I mean, this is completely non-understandable:
The WAN interface dropped (re0).
Then it reassigned LAN from em0_vlan1 to em0 (parent interface), and then deleted all assignments for em0_vlan3 (Wireless), em0_vlan4 (Server), which also deleted all firewall rules, services settings and such for those interfaces.

Why did it touch em0 at all? It was the WAN interface that become lost, not one of the LAN interfaces.
Its like it reset the interface assignments to factory.

Thats NOT going to recover anything, it will only make things worse.

I could understand, if it did assign WAN to em0 (since em0 was unassigned as im using VLAN on em0), as an attempt to recover. 

Noticed this pretty dangerous bug:

I accidentially losed the WAN NIC on the firewall (It had just come loose a bit).

This caused OPNSense to do a automatic unattended interface assignment reset, resetting everything that has with interfaces to default.

Of course, this caused all other settings related to the interfaces to be invalid, and thus caused a complete lockout of firewall - since I had firewall rules in place that prevents access to the GUI from "unauthorized" interfaces (And I had no backup).
Notice that it was the WAN interface that was lost - the system would just work fine without WAN, just that it would not have any internet.

This is COMPLETELY STUPID, as this prevents rescue of a system whose NIC breaks - a NIC can be easily replaced with a new.

If a interface is lost, for example if re0 is configured but it can't find the interface at boot - it should continue as-is, and just ignore the interface (and hope the interface comes back next boot - for example if its replaced or reseated).
By ignoring the interface, a system where that particular interface never returns again - for example a permanently broken NIC port - then that interface could be reassigned to a another NIC port, or be put on a VLAN as a temporary solution until hardware is replaced.

It should NEVER automatically touch interface settings. Let the system administrator do that instead.

You need to use RADV (found on DHCPv6 under Services) to "annouce" the prefix to the LAN interface. So the LAN host knows which gateway it should send the packets to.

Remember that IPv6 is NAT-less, thus the LAN host is talking directly to your upstream gateway. With IPv4, your LAN host talks to the firewall, and your firewall talks with the gateway.

If you use Static IP, you can annouce unmanaged or Router Only.

Found a pretty serious bug.
If the default route is a site to site OpenVPN client, the bootup process fails to set the route because its not yet connected.
When OpenVPN client is connected, the firewall seems to skip route application, causing the firewall to be left without any default route, until the OpenVPN client is manually restarted.

A good idea would be to ALWAYS recalculate routes when a OpenVPN client or server interface is started.

Log:

Jun 18 09:31:42
opnsense: /usr/local/etc/rc.newwanip: The command '/sbin/route delete -inet 'default'' returned exit code '1', the output was 'route: route has not been found delete net default fib 0: not in table'
Jun 18 09:31:42
opnsense: /usr/local/etc/rc.newwanip: ROUTING: setting IPv4 default route to 185.86.107.1
Jun 18 09:31:42
opnsense: /usr/local/etc/rc.newwanip: rc.newwanip: on (IP address: 185.86.107.140) (interface: WANVPN2[opt6]) (real interface: ovpnc3).
Jun 18 09:31:42
opnsense: /usr/local/etc/rc.newwanip: rc.newwanip: Informational is starting ovpnc3.
Jun 18 09:31:42
configd.py: [c0960b20-55fa-4432-9614-8e843f2d209a] rc.newwanip starting ovpnc3
Jun 18 09:31:42
kernel: ovpnc3: link state changed to UP
Jun 18 09:31:39
configd.py: [02b5ceac-fdff-4fec-9d73-bc503fb760ac] Reloading filter
Jun 18 09:31:37
configd.py: [f3e3e564-ef3a-4d11-b3fe-a72e8549ec9b] Reloading filter
Jun 18 09:31:37
kernel: ovpnc3: link state changed to DOWN
Jun 18 09:30:40

*** DOING MANUAL ovpnc3 RESTART HERE ***

configd.py: [86a8d2a5-2565-4b37-a12b-522674898a83] show system routing table
Jun 18 09:30:10
configd.py: [cc537973-ca7e-4a57-bc5d-fe6e1f118cfa] rc.newwanip starting ovpnc2
Jun 18 09:30:10
kernel: ovpnc2: link state changed to UP
Jun 18 09:30:09
configd.py: [e9c1e28a-373f-4452-8f55-1c9a7ea4c95b] rc.newwanip starting ovpnc3
Jun 18 09:30:09
kernel: ovpnc3: link state changed to UP
Jun 18 09:30:09
kernel:
Jun 18 09:30:09
kernel: done.
Jun 18 09:30:09
opnsense: /usr/local/etc/rc.bootup: The command '/sbin/route delete -inet '46.227.67.140/32' '193.235.65.193'' returned exit code '1', the output was 'route: route has not been found delete net 46.227.67.140: gateway 193.235.65.193 fib 0: not in table'
Jun 18 09:30:09
opnsense: /usr/local/etc/rc.bootup: The command '/sbin/route delete -inet '46.227.67.145/32' '193.235.65.193'' returned exit code '1', the output was 'route: route has not been found delete net 46.227.67.145: gateway 193.235.65.193 fib 0: not in table'
Jun 18 09:30:09
opnsense: /usr/local/etc/rc.bootup: The command '/sbin/route delete -inet '216.66.80.90/32' '193.235.65.193'' returned exit code '1', the output was 'route: route has not been found delete net 216.66.80.90: gateway 193.235.65.193 fib 0: not in table'
Jun 18 09:30:09
opnsense: /usr/local/etc/rc.bootup: ROUTING: setting IPv6 default route to 2001:470:27:1c::1
Jun 18 09:30:09
opnsense: /usr/local/etc/rc.bootup: The command '/sbin/route add -inet 'default' '185.86.107.1'' returned exit code '1', the output was 'route: writing to routing socket: Network is unreachable add net default: gateway 185.86.107.1 fib 0: Network is unreachable'
Jun 18 09:30:09
kernel: done.
Jun 18 09:30:09
opnsense: /usr/local/etc/rc.bootup: ROUTING: setting IPv4 default route to 185.86.107.1

I have 1 OpenVPN server, and 2 OpenVPN clients.
One of these OpenVPN clients are considered WAN (call this WANVPN2).

Roadwarriors should be able to connect to the OpenVPN server by connecting from the external IP of WANVPN2.

Now I stumbled upon a problem, and that is, that the OpenVPN server starts before the OpenVPN clients had the chance to connect. Thus the server will then receive traffic from WANVPN2, and then attempt to send this traffic out of WAN. Of course it does not reach the client (and if it reach the client, the client will obviously discard it).

Only way to remedy this, is to click 2 times on the green play button on the "OpenVPN server" definition. (restarting the server from the process list in dashboard won't help, only that helps is to disable OpenVPN server and reenable it).


This happens every reboot. Otherwise its totally fine.


I have a solution, and that is to add a floating rule, that will force any UDP-traffic from the firewall itself, with a source port of 1194, to exit through the WANVPN2 interface.
But even after adding a floating rule, with "quick matching" added, I get the following in the log:

@96 pass out log all flags S/SA keep state allow-opts label "let out anything from the firewall host itself"

Which means a inbuilt rule triggers. Any way to override this rule and tell the firewall that any "firewall:1194" packets should be treated differently?