Messages

Do you of any plans to make it available on only a subset of the interfaces ?

As a sort of a workaround you could bind unbound (with blacklists) only to one interface and dnsmasq on the others.

Also, keep in mind that Floating rules can have effect on this. They are parsed before interface rules.

I have disabled private networks on my wan and yet I still get traffic from 192.168.1. subnet.

I guess it is from my ISP router - they serve NATted network as well as public ip on the same port. But why does opnsense let this traffic in?

"Block private networks" on WAN (re1) is switched on, but yet:

Code Select Expand

# ping 192.168.1.254
PING 192.168.1.254 (192.168.1.254): 56 data bytes
64 bytes from 192.168.1.254: icmp_seq=0 ttl=64 time=0.580 ms
64 bytes from 192.168.1.254: icmp_seq=1 ttl=64 time=0.366 ms


The packets definitely seem to go out and back on the re1 interface:

Code Select Expand

[quote]# tcpdump -nn -i re1 host 192.168.1.254
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on re1, link-type EN10MB (Ethernet), capture size 262144 bytes
14:36:51.814864 IP 195.50.196.206 > 192.168.1.254: ICMP echo request, id 19307, seq 0, length 64
14:36:51.815392 IP 192.168.1.254 > 195.50.196.206: ICMP echo reply, id 19307, seq 0, length 64
14:36:52.818861 IP 195.50.196.206 > 192.168.1.254: ICMP echo request, id 19307, seq 1, length 64
14:36:52.819747 IP 192.168.1.254 > 195.50.196.206: ICMP echo reply, id 19307, seq 1, length 64
[/quote]

I checked that the address is not amoung configured addresses (ifconfig | grep 192.168), not routed (netstat -nr | grep 192.168) and not directly connected to the switch (arp -an | grep 192.168).

So I guess it is accessible through the WAN upstream gateway...

But shouldn't the "block private networks" switch make opnsense drop these packets?

Apparently it works for a new user belonging to admin group. But not for the original "root" user.
I do not think I have done anything with the API keys, unless it came from old config XML

Hi,

it seems I have botched this up somehow. New opnsense install, config imported from old.

When I click Check updates, it is checking forever, system.log shows:
Apr 21 10:10:39 mono api[86132]: uri /api/core/firmware/status authentication failed for api key kk
Apr 21 10:10:39 mono api[86132]: uri /api/core/firmware/info authentication failed for api key kk
Apr 21 10:10:39 mono api[86132]: uri /api/core/firmware/upgradestatus authentication failed for api key kk


Also, cannot install plugins/packages.

Try allowing UDP to 224.0.0.251 port 5353 from the network Apple TVs are sitting in. I don't know what Sonos uses, but Apple TV uses this to broadcast itself (mdns).

Well, if anybody else stumbles upon it - I found the loss of traffic reason. Appearantly as I had the route through zerotier networks to LAN defined with the actual LAN netmask /24, the real local route to LAN gets deleted when zerotier goes down. I was suggested that the route from zerotier to my gateway should be with a wider mask, in this case /23 did the trick.

LAN clients and opnsense are happy as they are using Longest prefix match logic and go with /24 and guys on the other side of zerotier are happy as /23 includes your /24 LAN provided that it won't collide with your other address spaces.

Question 1 - why did the zerotier address change on minor version upgrade - is still unanswered, but that is a minor issue as I could add the new one in ZeroTier Central.

Hi,

I have several troubles with zerotier now.

1) after upgrading from 20.1.3 -> 20.1.4 I discovered that zerotier was offline. Investigating the issue, found out that the zerotier address (sort of a unique id that identifies a host) of the opnsense machine has changed. Is that designed behaviour?

2) no biggie, went to ZeroTier central and added the new address. Went to look/configure zerotier in opnsense web gui and suddenly lost all LAN connectivity to opnsense. Totally baffled, power cycle, try again. Same result. It seems that when zerotier is enabled I now lose LAN connectivity to opnsense.

Any ideas?

Lets try to explain the issue again.
I know how crontab file as such works. I can also do #man 5 crontab
That is not the issue here.

I am talking about a web GUI here. There is no guarantee that it behaves like a crontab file. It would be nice if that was obvious from the GUI itself without trial and error and assumptions.

in most unix systems both 0 and 7 are sunday, I suppose it's the same for freeBSD

Yes, that is also what I assumed, but it would be nice if it was evident from GUI help itself.

[and]

How are the weekdays numbered in the cron jobs?

0-6 or 1-7 (is Sunday the first or last day of the week)?
or 0-7 (where 0 and 7 is understood as Sunday) like in the system?

It would make my mind at ease if there was an explanation in the GUI help. Currently it says "Enter the days of the week for the job to act, can also be a comma-separated list, * (each) or a range (ex. 1,2,3 or 1-3)"

Having crl-verify in Custom Options is a great idea. I can even use a different filename so it wont be overwritten. I'll have to check, what path survives a reboot.

I don't think openvpn restart is even necessary, I think openvpn reads CRL on each client connect.

Well, thank you for contributing, but neither of your answers addresses the question I asked in any way...

> Why don't you move the CA to OPNsense and manage it there?
As I said - I have several opnsense boxes which serve openvpn to clients. Clients have a certificate which is signed by a CA which all of the openvpn boxes trust. Even if i did the signing and revoking in an opnvpn box, I would still have to distribute the CRL to the rest of them - so it would solve nothing. Moreover - I am using the client certificate to authenticate clients against other services in other servers which also need the CRL.

I have a script that revokes a client and uploads the CRL to all the services involved. But I have not found a good way to do it in opnsense - and that is what I am asking. An API call or file path to where i can scp upload to update the CRL. Currently the only way to achieve that seems to be to update the CRL via admin interface manually.

Cron jobs have absolutely nothing to do with this matter.

I guess if there is no easier way, I will just make a curl script to emulate the upload via admin.

I understand that a copy of the CRL is saved locally.

I am currently uploading the CRL manually from admin every time I revoke a cert. As i have several Opnsense machines, it is quite cumbersome. I would like to automate this update either by SSH or API call or something like that.

We are signing our VPN user certificates outside OPNsense box.

Where does OPNsense save the CRL that is imported through the web gui?

Can I upload the CRL to OPNSense box without importing it through the web GUI? For instance with scp. Or have OPNsense pull the CRL from another server at an interval? Or upload it through an URL call?