Messages

[cannot HOLD]

The main focus of DynDNS is A/AAAA.

I agree, but I should point out and highlight that in DDNS mode, the dynadot DNS record cannot HOLD anything but A and AAAA entries.

For reasons mentioned by @Patrick M. Hausen one wouldn't want to update anything but A and AAAA using dyndns, but that is besides the point.

I might not exactly fit the homeuser profile, but my own intended use case is to update A and AAAA records for the same domain for which I use a third party email-hosting provider. So I will need to maintain a DNS record with A, AAAA, MX and TXT values.

Although only the A and AAAA records would be modified by opnsense.

For now I've pushed on by using the username field to toggle between DDNS and API mode, since that field was unused anyways, but it's definitely too obscure of a solution for my taste  :-\

[separate from the API key generated for full API access.]

Thanks! that worked well enough. However I hit a bump.

As it turns out, dynadot has a DDNS mode which you can optionally enable for your domain. It will generate a DDNS client key, separate from the API key generated for full API access. .

However, in DDNS mode your domain DNS record cannot hold MX, TXT or other values than A and AAAA, and as such, this will not work well for people who are perhaps hosting their email elsewhere.

In order to make this implementation user friendly, I would have to either

• make two plugins, one for Dynadot API mode, and one for Dynadot DDNS mode.

or

• make a plugin with custom configuration options in the opnsense UI

Any recommendations here?

Perfect, thank you!

I'm pretty much done with my implementation but I've coded my solution without testing or debugging it. Are there any simple strategies I can use for some rudiment manual testing?

[native python ddclient implementation]

I'm looking to contribute by adding support for 'dynadot.com' to the native python ddclient implementation mentioned here https://docs.opnsense.org/manual/dynamic_dns.html#general-settings.

From searching the forum I found indications that the native python implementation resides inside the os-ddclient plugin code base.

Could anyone point me in the right direction?

 :D

That did the trick! Thank you so much!👌

[Issue:]

I've configured an OpenVPN Server running on OPNsense 22.1.7.
My config is pretty basic.

10.0.0.0/24 for VPN,
192.168.1.0/24 for LAN,

Issue: While connected to my VPN, I'm unable to access any public/web site, this includes pinging DNS-servers like 8.8.8.8 or 1.1.1.1.

I do however have full access to the servers within my LAN, like my OPNsense router (192.168.1.1) and some other servers on my LAN.

I suspect I need to add a firewall rule that makes VPN clients able to 'surf the web' when connected, but Im not sure what might be the issue.

Help appreciated!

[Protocol]

You should read the rule like this:

(MYLAN) Interface
IPv4 *   MYLAN net   *   *   *   *   *   Default allow LAN to any
Every IPv4 packet which arrives (incoming) at "MYLAN Interface" is checked if
-IP is within the MYLAN range,
-Port *
-Destination *

if everything matches the paket is allowed.

Ok?

That is simple enough,
but what I really want to know is how I should read this rule:
Firewall rules for NEIGHBORLAN

Protocol	Source	Port	Destination	Port	Gateway	Schedule	Description
IPv4+6 *	*	*	MYLAN net	*	*	*	Block all traffic to MYLAN

Applying your formula I would think it reads something like:
> Every IPv4 and IPv6 packet leaving NEIGHBOUR LAN (outgoing)
is checked if
-IP is *
-Port *
-Destination within "MYLAN"
Block it.

But apparently that is not the reality, so how do I read this rule and what is the effect of it?

Also, if only incoming traffic is effected, why does the interface even allow me to add this rule in the first place?!

[Source]

I did some reading but frankly it didn't make it more clear to me. I guess my problem understanding this stems from how the rule I set up for NEIGHBOR Lan above clearly asks me to provide Source as well as Destination. This IMO implies that a blocking rule for any traffic with destination 'MYLAN' would be a valid configuration but from what i read that is then an 'outbound' firewall block which is not how OPNsense operates...  :o

Thanks! That did the trick, I added the same IPv4+6 blocking rule for traffic from MYLAN to NEIGHBORLAN and now I have no more bleed over from samba shares.  ;D

However this has made me realize something is flawed in my understanding of how the firewall operates. I am fairly familiar with how TCP/IP works, including the difference between UDP and TCP protocols etc.
My initial understanding made me reason like this:
- by blocking NEIGBORLAN to send any traffic to MYLAN, any attempt to send _requests_ AND _respond to requests_ would be blocked.
Obviously that wasn't the case.
My new Hypothesis is that:
- the bleed-over occurred because my computer on MYLAN sent some type of samba-broadcast request, which made it to NEIGBORLAN where the firewall allowed some device to "answer" that request (as it was instigated by a device on MYLAN).

Code Select Expand


MYLAN                                NEIGHBORLAN
rule in effect
CPU1           <----blocked----<     CPUX
CPU1               [nothing]         CPUX

rule _not_ in effect (bleed over)
CPU1           >----allowed---->     CPUX
CPU1           <----allowed----<     CPUX

Can someone confirm?

[Interface]

I've now ran the setup for some time and currently I'm experiencing some 'bleedover'.
In OS X, my neighbours SMB share is listed under 'shared' in my finder windows.

Here are (some) of my DHCPv4 leases

Interface	IP address	MAC address	Hostname
MYLAN	192.168.1.12	00:00:00:00:00:d2	access point
MYLAN	192.168.1.20	00:00:00:00:00:7b	amazon
NEIGHBORLAN	192.168.100.11	00:00:00:00:00:c0	access point
NEIGHBORLAN	192.168.100.16	00:00:00:00:00:d4	DESKTOP-PC
NEIGHBORLAN	192.168.100.18	00:00:00:00:00:46	iPhone-X

Firewall rules for MYLAN

Protocol	Source	Port	Destination	Port	Gateway	Schedule	Description
IPv4 *	MYLAN net	*	*	*	*	*	Default allow LAN to any rule
IPv6 *	MYLAN net	*	*	*	*	*	Default allow LAN IPv6 to any rule

Firewall rules for NEIGHBORLAN

Protocol	Source	Port	Destination	Port	Gateway	Schedule	Description
IPv4+6 *	*	*	MYLAN net	*	*	*	Block all traffic to MYLAN
IPv4 *	*	*	*	*	*	*	Default allow LAN to any rule
IPv6 *	*	*	*	*	*	*	Default allow LAN IPv6 to any rule

Does anyone know how I might block samba-detection bleed over?

 :D The box would be under my professional supervision so that's not a problem. I just got it up running and configured it to run the separate LANs on the different physical ports. Now how should I go about blocking of the two LANs from each other? I'm guessing it's in the firewall section of the OPN web configuration interface...

Great! I am not very close with my neighbor but I'm on a symmetrical gigabit fiber connection so I hope that will make up for it.  ;)

If anyone has more hands on experience of exactly what type of rules I need to set up that would be helpful.

Me and my neighbor wants to share internet connection. I run opnsense on hardware with 3 Ethernet ports so basically the idea is to use port A as WAN, port B as my LAN (I.e 192.168.1.*) and port C as my neighbors LAN (I.e 192.168.10.* or 10.0.0.*)

Both LAN 1 and LAN 2 needs to be able to access internet provided via the WAN port.
Furthermore, no communication should be allowed between lan 1 and lan 2.
I.e no samba file shares, bonjour discovery or other home network features should bleed over from one LAN to the other.

Would this be possible to achieve using OPNsense?