Topics

1

20.7 Legacy Series / Feature Request: Firewall rule IP addition

« on: October 16, 2020, 04:25:44 am »

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.

2

19.7 Legacy Series / Suggested settings to add to OpenVPN

« on: September 19, 2019, 05:13:16 am »

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"

3

17.7 Legacy Series / How I do to redirect "itself" into network?

« on: September 12, 2017, 12:25:15 pm »

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.

4

17.7 Legacy Series / [DANGEROUS] Losing a NIC should NEVER trigger any form of reset!

« on: August 07, 2017, 04:13:07 am »

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.

5

17.1 Legacy Series / Default route is not set @ boot if default route is OpenVPN network

« on: June 18, 2017, 11:40:39 am »

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

6

17.1 Legacy Series / OpenVPN server starts in wrong order - need to force outgoing traffic

« on: June 12, 2017, 02:10:36 pm »

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?