Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - rreboto

#1
I've been running my script to reboot the VM once a DNS request succeeds for the past few days.  In general, across ~150 reboots, it takes about 20 minutes for packets to pass through the firewall.  I've seen a couple 0 minute outliers, one 104 minute outlier, and seldomly it takes less than 5 minutes.

I don't really see a pattern around the timestamps to assume there's some cron job running that sorts things out.

Here's a sample of my script's output:

Oct 24 11:30:12 opnsense-pihole check-dns.sh[574]: worked! duration=20 minutes
Oct 24 11:52:40 opnsense-pihole check-dns.sh[574]: worked! duration=20 minutes
Oct 24 12:14:48 opnsense-pihole check-dns.sh[574]: worked! duration=19 minutes
Oct 24 12:36:36 opnsense-pihole check-dns.sh[575]: worked! duration=19 minutes
Oct 24 12:54:52 opnsense-pihole check-dns.sh[574]: worked! duration=15 minutes
Oct 24 13:17:25 opnsense-pihole check-dns.sh[575]: worked! duration=20 minutes
Oct 24 13:37:43 opnsense-pihole check-dns.sh[575]: worked! duration=17 minutes
Oct 24 14:00:10 opnsense-pihole check-dns.sh[576]: worked! duration=20 minutes
Oct 24 14:03:14 opnsense-pihole check-dns.sh[575]: worked! duration=0 minutes
Oct 24 14:25:21 opnsense-pihole check-dns.sh[575]: worked! duration=19 minutes
Oct 24 14:46:59 opnsense-pihole check-dns.sh[575]: worked! duration=19 minutes
Oct 24 15:03:10 opnsense-pihole check-dns.sh[574]: worked! duration=13 minutes
Oct 24 16:50:33 opnsense-pihole check-dns.sh[575]: worked! duration=104 minutes
Oct 24 17:04:38 opnsense-pihole check-dns.sh[574]: worked! duration=11 minutes
Oct 24 17:26:51 opnsense-pihole check-dns.sh[574]: worked! duration=19 minutes
Oct 24 17:44:27 opnsense-pihole check-dns.sh[577]: worked! duration=15 minutes
#2
While playing around with OPNsense on a spare machine recently, I connected its WAN port to my local network.  I noticed that:

- if you assign the WAN and DO NOT assign a LAN, you can access the webui from the WAN interface
- as soon as you assign the LAN interface, you can NO LONGER access the webui from the WAN

I'm not sure if this is what you are noticing or not, but I figured I would share that bit that I learned the hard way.

I would check that DHCP is enabled and configured for your LAN in OPNsense.  From there, plug your machine directly into the LAN port and confirm that you get an IP address from OPNsense.  At that point, you should be able to get to the webui on the gateway IP; likely http://x.x.x.1.

Hope this helps; good luck!
#3
Hello,

I have been able to get a Linux VM running with vm-bhyve on OPNsense, but I'm having trouble getting a stable network connection to a VLAN.

What I see is when the VM boots up the firewall filters the VM's tap interface and deny entries against the tap interface show in the logs. After roughly 18-20 minutes, deny logs stop and packets flow through the VLAN rule set.  I setup a script that makes DNS requests until it's successful, logs how long it takes, and reboots the VM.  Out of ~35 iterations, most times DNS request succeed in the 18-20 minute range.

I used `vm switch create` to make a switch on a vlan interface `ix2_vlan66`.  This creates a bridge interface, which I assigned in the UI, and an entry for it became available in the firewall rules section.  In the firewall I create a single rule that allows everything.  From what I can tell, that rule is used to allow DHCP to work; all other packets appear to be processed with the VLAN's rules.

Per instructions on "How to set up a LAN Bridge" [1] I set `net.link.bridge.pfil_member` to 0 and net.link.bridge.pfil_bridge to 1.

Any thoughts on what might be causing this?  Ideally the correct firewall rules would be applied to the VM immediately without the delay.  It seems like `net.link.bridge.pfil_member` and `net.link.bridge.pfil_bridge` tunables take effect on the tap interface/new members to the bridge after ~18 minutes.

Thank you!

[1] https://docs.opnsense.org/manual/how-tos/lan_bridge.html
#4
The instructions create a manual switch. I think the instructions may be missing the steps that a tap interface needs to be created and added to the bridge manually.

When you start the vm, can you check ifconfig and see if you have a tap interface and whether it was added to the bridge.  I suspect not, in which case you have to make the interface with ifconfig tap0 create and then add it to the bridge with ifconfig bridge0 addm tap0.

From there you might have to add it to the vm by running vm config <vmname> and adding network0_device=tap0.
#5
Thank you for this post!  I was able to follow it and get a jail up and running on OPNsense 23.1.5_4-amd64.  I had previously created a jail, but hadn't documented how, nor did I ever figure out how to give jails their own network interface; your documentation on creating a bridge in OPNSense and then creating an epair for each jail is great.

One thing I found different on my system compared to the docs was /etc/rc.conf.  Rather than a single file, I have a directory containing files for different services.  In my case, I created /etc/rc.conf.d/jail for the jails configuration:

root@OPNsense:~ # cat /etc/rc.conf.d/jail
jail_enable="YES"
jail_list="unifi-controller-13"


Thank you again for this writeup!   8)
#6
Virtual private networks / Add DNS entry for VPN client?
February 01, 2022, 04:49:39 PM
Hi all,

I have configured OPNSense to accept client OpenVPN connections.  I have a few remote servers that connect via VPN and I would like to connect to them, say with SSH, via hostname when I'm either on the network or connected via VPN myself.

I'm unable to find an option in the GUI to be able to create DNS entries for VPN clients using their VPN IP address.  Is this possible?  If it's not an option in the GUI is there some elegant way to achieve this?  In the past when installing and configuring OpenVPN on my own I had created a script that watches a status log file with the option `status <filename>` in the server configuration.

Thank you!