Messages

1

24.7 Production Series / unable to delete alias

« on: November 21, 2024, 06:40:33 am »

Hi,

how do I get rid of an unused firewall alias that appears as still being referenced and can not be deleted?

When I try to delete it, I'm getting an info that a rule is still using it, but I deleted the rule and then deleted the whole interface the rule was used with.  There is no way that this alias should still be used in any way.

So far, I was only to disable the alias.  It's for a host and contains an IPv4 address.

2

24.7 Production Series / Re: KEA: how to specify DNS server(s) per subnet?

« on: October 11, 2024, 06:15:34 pm »

Oh, cool, I didn't know that!  I pasted them with space(s) in between ...

3

24.7 Production Series / Re: KEA: how to specify DNS server(s) per subnet?

« on: October 11, 2024, 12:20:12 pm »

Thanks, it's working now!

I guess it didn't like that I copied and pasted two addresses at the same time into the field.

4

24.7 Production Series / Re: KEA: how to specify DNS server(s) per subnet?

« on: October 11, 2024, 03:44:49 am »

Thank you very much!

The help text of that option could be more clear.  Here's a suggestion:

Code: [Select]

Automatically update option data for relevant attributes as routers,
dns servers and ntp servers when applying settings from the gui.

Perhaps make that

Code: [Select]

Use data from the settings of this firewall for DHCP options given
to clients when the 'Auto collect option data' option is enabled.
With this option disabled, you can specify the DHCP options
given to clients manually.

... and rename that option to something like 'Use default DHCP options'.


PS: Is there a way to specify multiple DNS servers?  I tried that and it said I need to specify valid addresses.

5

24.7 Production Series / KEA: how to specify DNS server(s) per subnet?

« on: October 11, 2024, 01:49:25 am »

Hi,

how can I specify different DNS server(s) per subnet when using KEA?

6

Virtual private networks / Re: wireguard floating rules interface not present

« on: May 28, 2024, 12:57:28 am »

Sorry, it was all my fault: I failed to enable the interface after assigning it.  After enabling it, it now shows up

7

Virtual private networks / wireguard floating rules interface not present

« on: May 28, 2024, 12:42:22 am »

Hi,

I have set up a wireguard peer and assigned an interface to the connection.  Now I want to create a floating firewall rule to allow the remote peer on the wireguard interface to access hosts on a local subnet.  In this case, the peer is a single host.

But OPNsense doesn't allow me to pick the wireguard interface but only the wireguard group for creating floating rules

Since there will be some site-to-site connections as well that will also be hidden in the wireguard group, I can't use the wireguard group in the floating rules.  I need the particular interfaces that are hiding in the wirguard group.  The rules for all the wireguard conections will be different.

How do I get the wirguard interface usable to create floating firewall rules?

8

24.1 Legacy Series / Re: BIND is resolving to IPv6 instead of IPv4

« on: May 27, 2024, 10:43:26 pm »

Yes, the transport has always been bound to the IPv4 address of the server in pjsip.conf:

Code: [Select]

[transport-tls]
type=transport
protocol=tls
bind=192.168.3.50:5061
ca_list_file=/etc/pki/tls/certs/ca-bundle.crt
cert_file=/etc/asterisk/cert/cert.pem
priv_key_file=/etc/asterisk/cert/privkey.pem
method=tlsv1_2

If I wanted an IPv6 transport, I would have to set up another transport that binds to an IPv6 address.  Since I don't have static IPv6 addresses there's no point in doing that.  IPv6 is basically useless without static addresses just like IPv4.  ISPs need to be forced by law to give out static addresses on demand.

Still why doesn't it work with bind on OPNsense?

9

24.1 Legacy Series / Re: BIND is resolving to IPv6 instead of IPv4

« on: May 26, 2024, 08:08:45 pm »

[deleted by me, I misread a log file]

10

24.1 Legacy Series / Re: BIND is resolving to IPv6 instead of IPv4

« on: May 26, 2024, 08:03:16 pm »

maybe a quick "fix" for this is to make a dnsrewrite in opnsense-bind for this particular domain pointing to ipv4?

see here how this can be done in bind: https://www.redpill-linpro.com/techblog/2015/12/08/dns-rpz.html

Cool, thanks, this is good to know

IIRC, it would have the same effect as using the IPv4 address of the server of the VOIP provider instead of the FQDN of that server in the configuration of asterisk.  I don't want to do that because if the address changes, asterisk might contact the wrong server and thus could leak passwords.  Also, I'd be wondering why the phones suddenly don't work anymore and spend a day or so to figure out why because I forgot that I used the IPv4 address instead of the FQDN.  I don't want to do that.

11

24.1 Legacy Series / Re: BIND is resolving to IPv6 instead of IPv4

« on: May 26, 2024, 07:52:42 pm »

When I manually ping the server of the VOIP provider, ping uses an IPv6 address.  I have to use 'ping -4' to get an IPv4 address.  That also shows that asterisk must be asking for IPv4 and not for IPv6.

No, it shows that when you advise the client (ping) to use IPv4, it will ask for the IPv4 address of its target only.

It only does that when using 'ping -4'.  I don't know what asterisk does.  I only know that it gets IPv4 address with bind on Linux and and IPv6 address with bind on OPNsense.  That means that there is a problem with bind on OPNsense.

However, it wouldn't make sense for asterisk to request an IPv6 address for a transport that is bound to an IPv4 address.  And apparently doesn't do that because if it did, it would get an IPv6 address just like ping and 'ping -6' get.

Try it yourself: If you use "nslookup <target>", you will get both adresses. Which of those are used is then up to the client (which will default to IPv6 if it is able to use it).

Right.  And?

Why would a client request an IPv6 address when it doesn't need/want/use one?

Why would asterisk decide to use an IPv6 address instead of an IPv4 address depending on which system the name server is running on?  Asterisk doesn't know where bind runs.

With bind running on OPNsense, it doesn't work. I have verified that when using the IP address of the server of the VOIP provider instead of the host name, it works and asterisk registers.  Again the conclusion is that bind on OPNsense is incorrectly answering with an IPv6 address instead of an IPv4 address.

You are wrong. The default for DNS is to return all addresses (in no specific order) and it is up to the client to decide which it uses. That is by design, not "incorrect".

If that is so, then why does asterisk decide not to use the IPv4 address when bind is running on OPNsense?

But as I said, you can restrict OpnSense or even bind itself to only use IPv4, as is probably the case with your other bind instance.

No, the bind on Linux is not restricted to IPv4.  And no, if I were to restrict bind on OPNsense to IPv4, that would mean to turn off IPv6 entirely, which is not what I want.

Consider this: If you want bind on OpnSense to return IPv6 adresses as well as IPv4, and you have three options:

1. Ask for IPv4
2. Ask for IPv6
3. Ask for any IP

and you say, you want to be able to do 2. and 3. (since you do not want to disable IPv6 altogether), what does your client have to do in order to get IPv4? See?

I also want to be able to do 1..  I don't know what a client needs to do to ask for an IPv4 address since I never had to do any programming for getting IPv4 or IPv6 addresses.

I would guess that your server bind installation is restricted to IPv4 only like this.

No, there is no restriction to IPv6.  For example:

Code: [Select]

# ping ipv64.net
PING ipv64.net (2a01:4f8:192:1326::bad:c0de) 56 data bytes
64 bytes from ipv64.net (2a01:4f8:192:1326::bad:c0de): icmp_seq=1 ttl=57 time=12.4 ms
[...]


# dig ipv64.net

; <<>> DiG 9.18.26 <<>> ipv64.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5885
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 41379600a24aa64b010000006653753b6c1b0112247d26d9 (good)
;; QUESTION SECTION:
;ipv64.net.                     IN      A

;; ANSWER SECTION:
ipv64.net.              3446    IN      A       144.76.85.238

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Sun May 26 19:45:31 CEST 2024
;; MSG SIZE  rcvd: 82


# dig -t any ipv64.net

; <<>> DiG 9.18.26 <<>> -t any ipv64.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64751
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 9072464819cc397a0100000066537571f28842cc104a0ef2 (good)
;; QUESTION SECTION:
;ipv64.net.                     IN      ANY

;; ANSWER SECTION:
ipv64.net.              3143    IN      SOA     ns1.ipv64.net. hostmaster.ipv64.net. 4239685 10800 3600 604800 3600
ipv64.net.              3520    IN      AAAA    2a01:4f8:192:1326::bad:c0de
ipv64.net.              3392    IN      A       144.76.85.238
ipv64.net.              3143    IN      NS      ns1.ipv64.net.
ipv64.net.              3143    IN      NS      ns2.ipv64.net.
ipv64.net.              3143    IN      TXT     "v=spf1 mx a -all"
ipv64.net.              3143    IN      TXT     "google-site-verification=8aQ-Dd65zb-d8CCA121kSqkuOOHHzrpxEg9f8ADm7f8"
ipv64.net.              3143    IN      MX      10 mail.schroederdennis.de.

;; ADDITIONAL SECTION:
ns1.ipv64.net.          88807   IN      A       195.201.223.103
ns2.ipv64.net.          88807   IN      A       157.90.241.20
ns1.ipv64.net.          88807   IN      AAAA    2a01:4f8:c2c:559c::1
ns2.ipv64.net.          88807   IN      AAAA    2a01:4f8:c012:9c97::1

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (TCP)
;; WHEN: Sun May 26 19:46:25 CEST 2024
;; MSG SIZE  rcvd: 430


The only thing that may be suspicious is that dig shows the IPv4 address.  But it's apparently not a problem because I get the same behaviour when asking bind running on OPNsense:

Code: [Select]


dig -p 530 ipv64.net @192.168.3.1

; <<>> DiG 9.18.26 <<>> -p 530 ipv64.net @192.168.3.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37648
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 3d90bb4740ed5194010000006653763ec95d7c5786cc36bc (good)
;; QUESTION SECTION:
;ipv64.net.                     IN      A

;; ANSWER SECTION:
ipv64.net.              3600    IN      A       144.76.85.238

;; Query time: 55 msec
;; SERVER: 192.168.3.1#530(192.168.3.1) (UDP)
;; WHEN: Sun May 26 19:49:50 CEST 2024
;; MSG SIZE  rcvd: 82


dig -p 530 -t any ipv64.net @192.168.3.1

; <<>> DiG 9.18.26 <<>> -p 530 -t any ipv64.net @192.168.3.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21078
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 5148bcba6202632d010000006653769e52b873e71ac13dc5 (good)
;; QUESTION SECTION:
;ipv64.net.                     IN      ANY

;; ANSWER SECTION:
ipv64.net.              3600    IN      SOA     ns1.ipv64.net. hostmaster.ipv64.net. 4239843 10800 3600 604800 3600
ipv64.net.              3600    IN      AAAA    2a01:4f8:192:1326::bad:c0de
ipv64.net.              3504    IN      A       144.76.85.238
ipv64.net.              3600    IN      NS      ns1.ipv64.net.
ipv64.net.              3600    IN      NS      ns2.ipv64.net.
ipv64.net.              3600    IN      TXT     "google-site-verification=8aQ-Dd65zb-d8CCA121kSqkuOOHHzrpxEg9f8ADm7f8"
ipv64.net.              3600    IN      TXT     "v=spf1 mx a -all"
ipv64.net.              3600    IN      MX      10 mail.schroederdennis.de.

;; ADDITIONAL SECTION:
ns1.ipv64.net.          172704  IN      A       195.201.223.103
ns2.ipv64.net.          172704  IN      A       157.90.241.20
ns1.ipv64.net.          172704  IN      AAAA    2a01:4f8:c2c:559c::1
ns2.ipv64.net.          172704  IN      AAAA    2a01:4f8:c012:9c97::1

;; Query time: 37 msec
;; SERVER: 192.168.3.1#530(192.168.3.1) (TCP)
;; WHEN: Sun May 26 19:51:26 CEST 2024
;; MSG SIZE  rcvd: 430

So I assume that dig asks for IPv4 addresses unless instructed otherwise, unlike ping.

12

24.1 Legacy Series / Re: BIND is resolving to IPv6 instead of IPv4

« on: May 26, 2024, 12:42:36 am »

With a pjsip transport bound to an IPv4 address, of course I expect asterisk to ask for IPv4 addresses and not for IPv6 ones.  It obviously does that because with bind running on Linux it works and asterisk registers just fine.

When I manually ping the server of the VOIP provider, ping uses an IPv6 address.  I have to use 'ping -4' to get an IPv4 address.  That also shows that asterisk must be asking for IPv4 and not for IPv6.

With bind running on OPNsense, it doesn't work. I have verified that when using the IP address of the server of the VOIP provider instead of the host name, it works and asterisk registers.  Again the conclusion is that bind on OPNsense is incorrectly answering with an IPv6 address instead of an IPv4 address.

Of course I don't want to generally restrict clients to use IPv4 only or to prefer IPv4 instead of IPv6.  If I wanted that, I could better turn off IPv6 altogether.

So why is the bind version OPNsense buggy, and when will that be fixed?  Or, if it's not buggy, then why does asterisk get the wrong answers?

For now, I've gone back to using bind on my server.  But I would have liked to use bind on OPNsense.

13

24.1 Legacy Series / BIND is resolving to IPv6 instead of IPv4

« on: May 25, 2024, 08:23:31 pm »

Hi,

using the BIND plugin, it turns out that when asterisk running on my server requests an IP address of the server of the VOIP provider, OPNsense responds with IPv6 addresses instead of IPv4 addresses.

Running BIND on the server where asterisk is running, asterisk gets IPv4 addresses.

Since the trasports asterisk uses must be bound to the IPv4 address of the server because I can't get a static IPv6 prefix, the server of the VOIP provider becomes unreachable.

Shouldn't BIND on OPNsense resolve to IPv4 addresses when they are requested like BIND on the server does?  This seems like a bug.

How can I fix that other than to keep using the name server running on the server?

14

24.1 Legacy Series / kea and ipv6?

« on: May 24, 2024, 09:05:58 pm »

Hi,

are we supposed to still use DHCPv6 instead of kea for IPv6, or is there a way to have kea serve IPv6 as well?

If there is, what's the way?

15

General Discussion / use alias to specify DNS server

« on: May 22, 2024, 10:26:50 pm »

I need to  use an alias to specify a name server address for clients on a VLAN.

The address of the name server is an IPv6 address on another VLAN.  It's assigned to the server through DHCPv6.  I have created an alias for the server as a dynamic IPv6 host because the IPv6 prefix may change at any time.  So the only way to somehow specify the address of the DNS server seems to be using the alias.

Unfortunately, in the DHCPv6 configuration of the interface the client is connected to, the web interface won't let me use the alias to specify a name server but says "A valid IPv6 address must be specified for the primary/secondary DNS servers."

So how am I supposed to specify a valid IPv6 address for DNS server?


I've given the DNS server also the address fd53::11/16 on one of its interfaces.  I could use that as address for the DNS server for the clients, but opnsense does not have an interface in that network.  Since the interface for the VLAN the clients are in is tracking the WAN interface to get IPv6 addresses, there doesn't seem to be any way to put an additional IPv6 address on that interface, and the DNS server remains unreachable.

How can I give interfaces that are tracking the WAN interface for IPv6 addresses additional addresses?

I guess I could add another VLAN and give opnsense another interface to make the DNS server reachable, but that seems like a rather convoluted solution and overkill for a problem that should be easy to solve.