Messages

1

Virtual private networks / OpenVPN remote network behind ovpn client not reachable

« on: January 23, 2023, 08:23:10 pm »

Hi there,

I've got following setup: https://prnt.sc/uCpJIatM6ZQc

I'm trying to get connection between the 10.0.10.25 and the 10.11.104.5 hosts. The latter is a host behind a firewall I do not control.
There's a static route set on Site2's OPNsense to allow traffic to the 10.11.104.0/24 network via the 3rd party IP address in the 10.11.10.0/24 LAN. Pinging from the 10.11.10.0/24 LAN to 10.11.104.5 works without problems.

However when I try to ping 10.11.104.5 either through the VPN tunnel, or even just on Site2's OPNsense using the (local, generated) OVPN_TS interface (setting 'Source Address'), I am unable to do so.

Working from LAN:

# /usr/sbin/traceroute -w 2 -n  -m '10' -s '10.11.10.1'   '10.11.104.5'
traceroute to 10.11.104.5 (10.11.104.5) from 10.11.10.1, 10 hops max, 40 byte packets
 1  10.11.10.2  0.118 ms  0.049 ms  0.034 ms
 2  10.11.104.5  0.192 ms  0.094 ms  0.083 ms
 
Failing from the local tunnel interface:

# /usr/sbin/traceroute -w 2 -n  -m '4' -s '10.9.1.2'   '10.11.104.5'
traceroute to 10.11.104.5 (10.11.104.5) from 10.9.1.2, 4 hops max, 40 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 
The static route that was added is reflected in the routing table: Site2's OPNsense should know where to reach the 10.11.10.0/24 network:

Proto Destination       Gateway    Flags Use MTU Netif Netif (name)
ipv4   default         77.22.44.1   UGS   NaN   1500   vmx0   WANlink       
ipv4   10.0.10.0/24   10.9.1.1   UGS   NaN   1500   ovpnc1   OVPN_TS
ipv4   10.9.1.1      link#8      UH   NaN   1500   ovpnc1   OVPN_TS
ipv4   10.9.1.2      link#8      UHS   NaN   16384   lo0      Loopback
ipv4   10.11.104.0/24   10.11.10.2   UGS   NaN   1500   vmx1   LAN
(...)

I added 'allow all' rules on the OVPN_TS interface but I'm unable to get ping to work.

Any idea what I'm doing wrong?

2

Virtual private networks / Re: OpenVPN S2S: client to server OK but server to client fails

« on: January 21, 2023, 07:08:08 pm »

FWIW, the day after things worked fine.
I added some firewall rules at both sides on the LAN to allow the network at the other side. I think this was the solution.

3

Virtual private networks / OpenVPN S2S: client to server OK but server to client fails

« on: January 19, 2023, 09:50:11 pm »

Hi all,

I've set up an OpenVPN Site2Site over the public internet. The VPN connects well, no problems there.

Name   Remote Host   Virtual Addr   Connected Since   Bytes Sent   Bytes Received   Status   
My_OpenVPN UDP:1194   79.12.15.170   10.9.1.1   2023-01-19 20:58:26   46 KB   35 KB   up

I use 10.9.1.0/24 as tunnel network (per the above) and the subnets at each site are 10.7.1.0/24 (LAN site1) and 10.8.1.0/24 (LAN site2). Site1 is runs the OpenVPN server; site2 runs the client.

Firewall rules were set to allow all traffic on the OpenVPN tunnel (regardless of source), at both sides:

   Protocol   Source   Port   Destination   Port   Gateway   Schedule   Description       
        IPv4 *   *   *   *   *   *   *   Allow_OpenVPN_traffic

On the OPNsense shell of site1, I can ping 10.9.1.1 (local IP address of the tunnel) and 10.9.1.2 (which is the other side/site).

On site2 I can reach site1 just fine (I can ping 10.7.1.0/24 addresses).
However I cannot reach any IP address from site1 to site2 (e.g. 10.8.1.2).

An extract of the routing table of site2 (https://10.8.1.1/ui/diagnostics/interface/routes) shows entries of site1's 10.7.1.0 network:

ipv4   default   79.12.15.1   UGS   NaN   1500   vmx0   My_WAN
ipv4   10.7.1.0/24   10.9.1.1   UGS   NaN   1500   ovpnc1           
ipv4   10.9.1.1   link#8   UH   NaN   1500   ovpnc1           
ipv4   10.9.1.2   link#8   UHS   NaN   16384   lo0   Loopback       
ipv4   10.8.1.0/24   link#2   U   NaN   1500   vmx1   lan   
 
The same applies for site1 (i.e. site2 routes exist).

I rebooted both sides just in case to no avail.

Any idea where things are going wrong?

4

22.1 Legacy Series / Gateway "cannot be deleted because it is in use on Gateway Group" but it is not

« on: April 25, 2022, 11:25:36 am »

Hi,

I'm getting following error when trying to delete a Single Gateway:

The following input errors were detected:

• Gateway X cannot be deleted because it is in use on Gateway Group Y
• Gateway X cannot be deleted because it is in use on Gateway Group Z

I checked GWG Y and Z though and it can be confirmed that these are NOT using this Single Gateway X in any of the tiers.

Any idea on how to properly delete the Single Gateway?
I had already disabled it but I keep on getting "Status failed gateway_alert" messages from Monit.

5

21.1 Legacy Series / Re: Help with configuration Munin

« on: February 15, 2021, 08:55:58 am »

the "nc 192.168.14.1 4949" command returns the following response:

Code: [Select]

root@Bravo:~ # nc 192.168.14.1 4949
# munin node at Bravo
list
cpu df df_inode hddtemp_smartctl if_bge0 if_bge1 if_errcoll_bge0 if_errcoll_bge1 if_packets_bge0 if_packets_bge1 iostat load memory netstat ntp_193.219.28.2 ntp_213.199.225.40 ntp_54.37.233.160 ntp_94.23.94.78 ntp_kernel_err ntp_kernel_pll_freq ntp_kernel_pll_off ntp_offset ntp_states open_files smart_ada0 swap systat uptime users
I think that is the correct answer. What is your opinion? 

Yep looks good.

I still don't know where exactly should I put it :

Code: [Select]

[OPNsense.mydomain.local]
        address 10.0.10.1
        use_node_name yes

/usr/local/etc/munin/munin-node.conf?

Nope, just in the host definition section under munin.conf. The munin-node.conf file contains config of the node (client). Munin.conf is the one for the master.
In munin.conf you'd typically have an entry for the master itself, like:

Code: [Select]

[Monitoring.mydomain.local]
        address 127.0.0.1
        use_node_name yes
        hddtemp.sda.critical 60
        hddtemp.sdb.critical 60
And then you just add another one:

Code: [Select]

[OPNsense.mydomain.local]
        address 10.0.10.1
        use_node_name yes
Once you have this set, you should be able to use "/usr/share/munin/munin-update --debug --nofork --host OPNsense.mydomain.local" if things aren't working yet, and inspect for errors.

6

Tutorials and FAQs / Re: [Tutorial] Munin-node OPNsense

« on: February 14, 2021, 09:33:29 am »

Done - main message is to try http://guide.munin-monitoring.org/en/latest/tutorial/troubleshooting.html/

7

21.1 Legacy Series / Re: Help with configuration Munin

« on: February 14, 2021, 09:32:13 am »

Did you have look at the troubleshooting section of munin on http://guide.munin-monitoring.org/en/latest/tutorial/troubleshooting.html?

Particularly the telnet/nc connection is an important one to verify: if plugins are listed and if results can be fetched, then the issue is likely on the master, if no plugins are listed then it's for sure on the client.

Code: [Select]

$ nc 10.0.10.1 4949
# munin node at OPNsense-v1
list
cpu df df_inode if_em0 if_errcoll_em0 if_errcoll_pppoe2 if_errcoll_pppoe3 if_errcoll_vmx0 if_errcoll_vmx1 if_errcoll_vmx2 if_errcoll_vmx3 if_errcoll_vmx4 if_errcoll_vmx5 if_errcoll_vmx6 if_errcoll_vmx7 if_errcoll_vmx8 if_packets_em0 if_packets_pppoe2 if_packets_pppoe3 if_packets_vmx0 if_packets_vmx1 if_packets_vmx2 if_packets_vmx3 if_packets_vmx4 if_packets_vmx5 if_packets_vmx6 if_packets_vmx7 if_packets_vmx8 if_pppoe2 if_pppoe3 if_vmx0 if_vmx1 if_vmx2 if_vmx3 if_vmx4 if_vmx5 if_vmx6 if_vmx7 if_vmx8 iostat load memory netstat ntp_kernel_err ntp_kernel_pll_freq ntp_kernel_pll_off ntp_offset ntp_states open_files swap systat uptime users
fetch cpu
user.value 384068
nice.value 0
system.value 712836
interrupt.value 21338
idle.value 167495170
.

I see you attempted a port probe but did not try to do a 'list' or 'fetch cpu' for example.

If all looks fine, next step I'd take is to manually run the service from the munin user on the master:

Code: [Select]

root@server:~# su - munin --shell=/bin/bash
munin@server:~$ /usr/share/munin/munin-update --debug --nofork --host OPNsense.mydomain.com
2021/02/14 09:25:43 [DEBUG] Creating new lock file /var/run/munin/munin-update.lock
2021/02/14 09:25:43 [DEBUG] Creating lock : /var/run/munin/munin-update.lock succeeded
2021/02/14 09:25:43 [INFO]: Starting munin-update
2021/02/14 09:25:46 [DEBUG] Creating new lock file /var/run/munin/munin-mydomain.com-OPNsense.mydomain.com.lock
2021/02/14 09:25:46 [DEBUG] Creating lock : /var/run/munin/munin-mydomain.com-OPNsense.mydomain.com.lock succeeded
2021/02/14 09:25:46 [DEBUG] Reading state for mydomain.com-OPNsense.mydomain.com in /var/lib/munin/state-mydomain.com-OPNsense.mydomain.com.storable
2021/02/14 09:25:46 [INFO] starting work in 15868 for OPNsense.mydomain.com/10.0.10.1:4949.
2021/02/14 09:25:46 TLS set to "disabled".
2021/02/14 09:25:46 [DEBUG] Negotiating capabilities
2021/02/14 09:25:46 [DEBUG] Writing to socket: "cap multigraph dirtyconfig
".
2021/02/14 09:25:46 [DEBUG] Node says /cap multigraph dirtyconfig/
2021/02/14 09:25:46 [DEBUG] Writing to socket: "list OPNsense-v1
".
2021/02/14 09:25:46 [DEBUG] for my if_errcoll_vmx5 (if_errcoll_vmx5 if_errcoll_vmx1 if_packets_vmx8 df if_packets_vmx6 if_em0 if_vmx3 if_vmx2 if_errcoll_pppoe3 ntp_kernel_pll_freq ntp_kernel_err if_vmx7 if_errcoll_vmx8 if_packets_vmx5 if_packets_vmx1 ntp_kernel_pll_off users load if_vmx8 if_errcoll_vmx6 if_packets_pppoe3 if_vmx1 if_vmx5 ntp_offset if_errcoll_vmx2 if_pppoe2 open_files if_packets_vmx7 iostat swap if_errcoll_vmx0 memory if_packets_vmx4 uptime if_packets_vmx3 netstat if_packets_pppoe2 if_pppoe3 if_packets_em0 if_errcoll_vmx7 ntp_states if_packets_vmx2 if_vmx0 if_packets_vmx0 if_vmx4 systat df_inode cpu if_errcoll_vmx4 if_errcoll_em0 if_errcoll_vmx3 if_errcoll_pppoe2 if_vmx6)
2021/02/14 09:25:46 [DEBUG] Fetching service configuration for 'if_errcoll_vmx5'
2021/02/14 09:25:46 [DEBUG] Writing to socket: "config if_errcoll_vmx5
".
2021/02/14 09:25:46 [DEBUG] Reading from socket: "graph_order ierrors oerrors collisions\ngraph_title vmx5 Errors & Collisions\ngraph_args --base 1000\ngraph_vlabel events / ${graph_period}\ngraph_category network\ngraph_info This graph shows the amount of errors and collisions on the vmx5 network interface.\nierrors.label Input Errors\nierrors.type COUNTER\noerrors.label Output Errors\noerrors.type COUNTER\ncollisions.label Collisions\ncollisions.type COUNTER".
2021/02/14 09:25:46 [DEBUG] config: 0.05001 sec for 'if_errcoll_vmx5' on OPNsense.mydomain.com/10.0.10.1/4949
2021/02/14 09:25:46 [DEBUG] Now parsing config output from plugin if_errcoll_vmx5 on OPNsense.mydomain.com
2021/02/14 09:25:46 [DEBUG] update_rate 0 for if_errcoll_vmx5 on OPNsense.mydomain.com/10.0.10.1:4949
2021/02/14 09:25:46 [DEBUG] No service data for if_errcoll_vmx5, fetching it
2021/02/14 09:25:46 [DEBUG] Writing to socket: "fetch if_errcoll_vmx5
".
2021/02/14 09:25:46 [DEBUG] data: 0.045926 sec for 'if_errcoll_vmx5' on OPNsense.mydomain.com/10.0.10.1/4949
2021/02/14 09:25:46 [DEBUG] Now parsing fetch output from plugin if_errcoll_vmx5 on OPNsense.mydomain.com/10.0.10.1:4949
2021/02/14 09:25:46 [FETCH from if_errcoll_vmx5] ierrors.value 0
2021/02/14 09:25:46 [FETCH from if_errcoll_vmx5] Storing 0 in ierrors
2021/02/14 09:25:46 [FETCH from if_errcoll_vmx5] oerrors.value 0
2021/02/14 09:25:46 [FETCH from if_errcoll_vmx5] Storing 0 in oerrors
2021/02/14 09:25:46 [FETCH from if_errcoll_vmx5] collisions.value 0
2021/02/14 09:25:46 [FETCH from if_errcoll_vmx5] Storing 0 in collisions
2021/02/14 09:25:46 [DEBUG] asking for a rrd of size : normal
(and so on)


8

Tutorials and FAQs / Re: [Tutorial] Munin-node OPNsense

« on: February 13, 2021, 07:58:25 pm »

On the munin master system, so it knows to reach out to the address of OPNsense and can start collecting.

9

Tutorials and FAQs / Re: [Tutorial] Munin-node OPNsense

« on: January 27, 2021, 01:21:25 pm »

At least for me, it wasn't. No munin plugins were enabled with the default install (tried by telnetting to opnsense and doing "list" - nothing showed up).

10

Tutorials and FAQs / [Tutorial] Munin-node OPNsense

« on: January 27, 2021, 10:02:59 am »

Since OPNsense 20.1, the plugin munin-node is available. No need to use the FreeBSD repo any longer.

The below is a mini-howto to install and configure munin-node on OPNsense 20.7.

Steps to take:
- Install the plugin "os-munin-node" through the GUI on System: Firmware: Plugins
- On the GUI, enable munin-node and set the proper server/network that may connect to munin: Services: Munin-Node: General
- Ensure your firewall rules allow access to munin-node (TCP port 4949)
- Enable SSH access to configure munin-node further
- Run "munin-node-configure --suggest" to get a suggestion on which plugins can be activated. NOTE: this command can take a *long* time to execute (4 minutes or so on my 4 CPU/6GB RAM system) without any output... Do " munin-node-configure --debug --suggest" to get more verbose output.
- Inspect what the suggestions are; if agreed run "munin-node-configure --debug --shell" to generate the shell commands. For me, these were:

Code: [Select]

ln -s '/usr/local/share/munin/plugins/cpu' '/usr/local/etc/munin/plugins/cpu'
ln -s '/usr/local/share/munin/plugins/df' '/usr/local/etc/munin/plugins/df'
ln -s '/usr/local/share/munin/plugins/df_inode' '/usr/local/etc/munin/plugins/df_inode'
ln -s '/usr/local/share/munin/plugins/if_' '/usr/local/etc/munin/plugins/if_em0'
ln -s '/usr/local/share/munin/plugins/if_' '/usr/local/etc/munin/plugins/if_pppoe2'
ln -s '/usr/local/share/munin/plugins/if_' '/usr/local/etc/munin/plugins/if_pppoe3'
ln -s '/usr/local/share/munin/plugins/if_' '/usr/local/etc/munin/plugins/if_vmx0'
ln -s '/usr/local/share/munin/plugins/if_' '/usr/local/etc/munin/plugins/if_vmx1'
ln -s '/usr/local/share/munin/plugins/if_' '/usr/local/etc/munin/plugins/if_vmx2'
ln -s '/usr/local/share/munin/plugins/if_' '/usr/local/etc/munin/plugins/if_vmx3'
ln -s '/usr/local/share/munin/plugins/if_' '/usr/local/etc/munin/plugins/if_vmx4'
ln -s '/usr/local/share/munin/plugins/if_' '/usr/local/etc/munin/plugins/if_vmx5'
ln -s '/usr/local/share/munin/plugins/if_' '/usr/local/etc/munin/plugins/if_vmx6'
ln -s '/usr/local/share/munin/plugins/if_' '/usr/local/etc/munin/plugins/if_vmx7'
ln -s '/usr/local/share/munin/plugins/if_' '/usr/local/etc/munin/plugins/if_vmx8'
ln -s '/usr/local/share/munin/plugins/if_errcoll_' '/usr/local/etc/munin/plugins/if_errcoll_em0'
ln -s '/usr/local/share/munin/plugins/if_errcoll_' '/usr/local/etc/munin/plugins/if_errcoll_pppoe2'
ln -s '/usr/local/share/munin/plugins/if_errcoll_' '/usr/local/etc/munin/plugins/if_errcoll_pppoe3'
ln -s '/usr/local/share/munin/plugins/if_errcoll_' '/usr/local/etc/munin/plugins/if_errcoll_vmx0'
ln -s '/usr/local/share/munin/plugins/if_errcoll_' '/usr/local/etc/munin/plugins/if_errcoll_vmx1'
ln -s '/usr/local/share/munin/plugins/if_errcoll_' '/usr/local/etc/munin/plugins/if_errcoll_vmx2'
ln -s '/usr/local/share/munin/plugins/if_errcoll_' '/usr/local/etc/munin/plugins/if_errcoll_vmx3'
ln -s '/usr/local/share/munin/plugins/if_errcoll_' '/usr/local/etc/munin/plugins/if_errcoll_vmx4'
ln -s '/usr/local/share/munin/plugins/if_errcoll_' '/usr/local/etc/munin/plugins/if_errcoll_vmx5'
ln -s '/usr/local/share/munin/plugins/if_errcoll_' '/usr/local/etc/munin/plugins/if_errcoll_vmx6'
ln -s '/usr/local/share/munin/plugins/if_errcoll_' '/usr/local/etc/munin/plugins/if_errcoll_vmx7'
ln -s '/usr/local/share/munin/plugins/if_errcoll_' '/usr/local/etc/munin/plugins/if_errcoll_vmx8'
ln -s '/usr/local/share/munin/plugins/if_packets_' '/usr/local/etc/munin/plugins/if_packets_em0'
ln -s '/usr/local/share/munin/plugins/if_packets_' '/usr/local/etc/munin/plugins/if_packets_pppoe2'
ln -s '/usr/local/share/munin/plugins/if_packets_' '/usr/local/etc/munin/plugins/if_packets_pppoe3'
ln -s '/usr/local/share/munin/plugins/if_packets_' '/usr/local/etc/munin/plugins/if_packets_vmx0'
ln -s '/usr/local/share/munin/plugins/if_packets_' '/usr/local/etc/munin/plugins/if_packets_vmx1'
ln -s '/usr/local/share/munin/plugins/if_packets_' '/usr/local/etc/munin/plugins/if_packets_vmx2'
ln -s '/usr/local/share/munin/plugins/if_packets_' '/usr/local/etc/munin/plugins/if_packets_vmx3'
ln -s '/usr/local/share/munin/plugins/if_packets_' '/usr/local/etc/munin/plugins/if_packets_vmx4'
ln -s '/usr/local/share/munin/plugins/if_packets_' '/usr/local/etc/munin/plugins/if_packets_vmx5'
ln -s '/usr/local/share/munin/plugins/if_packets_' '/usr/local/etc/munin/plugins/if_packets_vmx6'
ln -s '/usr/local/share/munin/plugins/if_packets_' '/usr/local/etc/munin/plugins/if_packets_vmx7'
ln -s '/usr/local/share/munin/plugins/if_packets_' '/usr/local/etc/munin/plugins/if_packets_vmx8'
ln -s '/usr/local/share/munin/plugins/iostat' '/usr/local/etc/munin/plugins/iostat'
ln -s '/usr/local/share/munin/plugins/load' '/usr/local/etc/munin/plugins/load'
ln -s '/usr/local/share/munin/plugins/memory' '/usr/local/etc/munin/plugins/memory'
ln -s '/usr/local/share/munin/plugins/netstat' '/usr/local/etc/munin/plugins/netstat'
ln -s '/usr/local/share/munin/plugins/ntp_' '/usr/local/etc/munin/plugins/ntp_45.87.76.3'
ln -s '/usr/local/share/munin/plugins/ntp_kernel_err' '/usr/local/etc/munin/plugins/ntp_kernel_err'
ln -s '/usr/local/share/munin/plugins/ntp_kernel_pll_freq' '/usr/local/etc/munin/plugins/ntp_kernel_pll_freq'
ln -s '/usr/local/share/munin/plugins/ntp_kernel_pll_off' '/usr/local/etc/munin/plugins/ntp_kernel_pll_off'
ln -s '/usr/local/share/munin/plugins/ntp_offset' '/usr/local/etc/munin/plugins/ntp_offset'
ln -s '/usr/local/share/munin/plugins/ntp_states' '/usr/local/etc/munin/plugins/ntp_states'
ln -s '/usr/local/share/munin/plugins/open_files' '/usr/local/etc/munin/plugins/open_files'
ln -s '/usr/local/share/munin/plugins/swap' '/usr/local/etc/munin/plugins/swap'
ln -s '/usr/local/share/munin/plugins/systat' '/usr/local/etc/munin/plugins/systat'
ln -s '/usr/local/share/munin/plugins/uptime' '/usr/local/etc/munin/plugins/uptime'
ln -s '/usr/local/share/munin/plugins/users' '/usr/local/etc/munin/plugins/users'
- Paste the listed shell commands so they get executed
- Restart munin-node: # service munin-node restart

Code: [Select]

# service munin-node restart
Stopping munin_node.
Waiting for PIDS: 46787.
Starting munin_node.
- (Optional) Verify whether connectivity from the munin master to OPNsense is OK and whether all plugins are listed:

Code: [Select]

root@srv-8:~# nc 10.0.10.1 4949
# munin node at OPNsense-v1
list
cpu df df_inode if_em0 if_errcoll_em0 if_errcoll_pppoe2 if_errcoll_pppoe3 if_errcoll_vmx0 if_errcoll_vmx1 if_errcoll_vmx2 if_errcoll_vmx3 if_errcoll_vmx4 if_errcoll_vmx5 if_errcoll_vmx6 if_errcoll_vmx7 if_errcoll_vmx8 if_packets_em0 if_packets_pppoe2 if_packets_pppoe3 if_packets_vmx0 if_packets_vmx1 if_packets_vmx2 if_packets_vmx3 if_packets_vmx4 if_packets_vmx5 if_packets_vmx6 if_packets_vmx7 if_packets_vmx8 if_pppoe2 if_pppoe3 if_vmx0 if_vmx1 if_vmx2 if_vmx3 if_vmx4 if_vmx5 if_vmx6 if_vmx7 if_vmx8 iostat load memory netstat ntp_45.87.76.3 ntp_kernel_err ntp_kernel_pll_freq ntp_kernel_pll_off ntp_offset ntp_states open_files swap systat uptime users
- Configure the OPNsense host on the munin master:

Code: [Select]

[OPNsense.mydomain.local]
        address 10.0.10.1
        use_node_name yes
- Restart munin on master:

Code: [Select]

# service munin restart
stop: Unknown instance:
munin stop/waiting
- Wait for your munin interval (default 5 mins) and enjoy initial OPNsense statistics generated on munin master

11

20.7 Legacy Series / Re: Changing Gateway name

« on: January 26, 2021, 08:46:45 am »

Same for a Gateway group, by the way:

The following input errors were detected:
Changing name on a gateway group is not allowed.

12

20.7 Legacy Series / Changing Gateway name

« on: January 25, 2021, 06:29:49 pm »

Hi there,

One of my WAN connections had its connection type changed from DHCP to PPPoE.
However on the Gateways listing, I still get "ISP1_DHCP" and cannot get rid of the DHCP naming: when editing the GW, I get:

The following input errors were detected:
Changing name on a gateway is not allowed.

Just to avoid any misunderstandings when I take a look at this page in a year or so from now... is there any way to change the GW name manually?

Thanks.

13

20.7 Legacy Series / Re: Dynamic DNS client: set from_ip or from_interface?

« on: January 24, 2021, 08:00:09 pm »

Hmm, apologies, it's that simple indeed. Not sure why but I overlooked the interface for some reason. Thanks!

14

20.7 Legacy Series / Gateway group: difference in handling between OPNsense and pfSense

« on: January 24, 2021, 07:17:10 pm »

Hi,

I'm trying to move my firewall from pfSense to OPNsense but am a bit puzzled regarding Gateway Groups.
In the MultiWAN guide I read that when picking a GW group for a particular network, traffic intended for the firewall itself will be routed wrongly:

This rule will utilize the gateway group for all traffic coming from our LAN network. This also means that traffic intended for the firewall itself will be routed in this (wrong) direction. That is why Step 5 is needed for our DNS traffic going to and coming from our DNS forwarder on the firewall itself.

My pfSense is at 10.0.0.1 and has GW groups configured for the interface.
My OPNsense is at 10.0.10.18 currently and has similar GW groups configured.
No particular firewall rules are added for DNS traffic on either system.

Code: [Select]

C:\>nslookup
Default Server:  UnKnown
Address:  10.0.10.22

> server 10.0.10.1
Default Server:  [10.0.10.1]
Address:  10.0.10.1

> google.com
Server:  [10.0.10.1]
Address:  10.0.10.1

Non-authoritative answer:
Name:    google.com
Addresses:  2a00:1450:400e:809::200e
          216.58.211.110

> server 10.0.10.18
Default Server:  [10.0.10.18]
Address:  10.0.10.18

> google.com
Server:  [10.0.10.18]
Address:  10.0.10.18

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Request to [10.0.10.18] timed-out

---> Adding a rule to allow DNS traffic on OPNsense <---

> google.com
Server:  [10.0.10.18]
Address:  10.0.10.18

Non-authoritative answer:
Name:    google.com
Addresses:  2a00:1450:400e:80d::200e
          172.217.168.238

>
Can anyone explain why this is the case? What are the advantages of doing it the OPNsense way?
As it comes with annoyances: all services that need to be available on OPNsense need to have a firewall rule added. Not just DNS, but also SSH, Munin-node, ..., and this for all the interfaces/VLANs that exist.

15

20.7 Legacy Series / [Resolved] Dynamic DNS client: set from_ip or from_interface?

« on: January 24, 2021, 05:49:25 pm »

Hi there,

I've got two WANs with IP addresses that might change (although they don't do so often).
I'd like to be able to connect to my network from wherever I am, through either of the WANs, so I have two dynamic addresses (isp1-myname.mydnsprovider.tld and isp2-myname.mydnsprovider.tld).

However in Services: Dynamic DNS I cannot pick which interface to use for DynDNS. So both addresses are set to the same (default) WAN IP address.
Is there another way to configure this somehow?