Messages

1

General Discussion / Re: Suricata detecting outbound SNMP on WAN interface

« on: January 11, 2022, 06:24:57 pm »

Windows stalking a HP printer over VPN?

I don't think so. Traffic to private IP ranges should be blocked by the firewall from leaking out onto the WAN (and I know I have those rules in place to do so), so this shouldn't be traffic coming from any LAN. It has to be generated by opnsense itself and it seems to be originating right at the WAN port. I'm running on bare metal so there is no hypervisor or host that could be doing this, either.

pmhausen, I'll try the tcpdump command later today after the workday.

2

General Discussion / Re: Suricata detecting SNMP on WAN interface

« on: January 11, 2022, 02:51:58 am »

<bump> and additional info:
I'm only running 4 additional plugins:
os-dmidecode
os-dyndns
wireguard-go
os-redis

I have 2 WAN connections with 2 gateways (primary and failover), but even if I shut down the failover and put a check on "Disable Gateway Monitoring", I still see the ICMP packets logged in IDS.

Still want to know what is sending those SNMP probes from the public IP of the WAN1 port. What's interesting is that there are no probes being sent form the WAN2 port, although it's truly only a failover, not a load balance, and the WAN2 connection is only active if WAN1 fails.

3

General Discussion / Suricata detecting outbound SNMP on WAN interface

« on: January 05, 2022, 12:05:45 am »

I don't have SNMP services installed, but Suricata is consistently logging and blocking SNMP traffic on the WAN interface going to a private IP. I don't use that private IP range on any LAN or VLANs I have.

Timestamp  |SID  |Action |Source |Port |Destination |Port |Alert 2022-01-04T14:59:45.775134-0800 | 2101411 | blocked | (my WAN1 public IP) | 8323 | 10.10.20.60 | 161 | GPL SNMP public access udp 2022-01-04T14:59:45.775134-0800 | 2101411 | blocked | (my WAN1 public IP) | 8323 | 10.10.20.60 | 161 | GPL SNMP public access udp 2022-01-04T14:59:36.676334-0800 | 2101411 | blocked | (my WAN1 public IP) | 8323 | 10.10.20.60 | 161 | GPL SNMP public access udp 2022-01-04T14:59:36.676334-0800 | 2101411 | blocked | (my WAN1 public IP) | 8323 | 10.10.20.60 | 161 | GPL SNMP public access udp 2022-01-04T14:59:26.612630-0800 | 2101411 | blocked | (my WAN1 public IP) | 8323 | 10.10.20.60 | 161 | GPL SNMP public access udp sudo sockstat -4 doesn't show any processes listening on port 161. How can I track down what seems to be sending SNMP traffic from the WAN interface?

4

20.7 Legacy Series / Re: Adding VLANs kills Traffic

« on: November 28, 2020, 03:32:03 am »

So - I upgraded to 20.7.5, added another VLAN and this time I did not have to reboot and everything just worked. Not sure if there was a bug in the older version or what. Eh.

5

20.7 Legacy Series / Re: Intra VLAN performance issues when WAN has issues

« on: November 26, 2020, 11:03:06 pm »

I'm sorry I have nothing solid to contribute, but it sounds like an issue with how the gateways between VLANs are set up. Personally, I never wrapped my head around the gateway config in opnsence, so I'm hoping seeing responses to this thread can shed some light on how the gateways work.

6

20.7 Legacy Series / Adding VLANs kills Traffic

« on: November 26, 2020, 10:57:31 pm »

I'm running 20.7.4 on a ProtectCLI 6-port device (6 Intel 82583V Ethernet NIC ports). I'm using 3 of those ports. 2 are different WAN ports, and one is my internal LAN port. I have my home network running as the native VLAN on the LAN port, but also have a couple VLANs going to my switches that I use for various purposes.

LAN port is "em1".
I yesterday, I needed to create 3 VLANs for a lab environment to set up some equipment. I went to "Interfaces", "Other Types", "VLANs". Every time I added a vlan to em1 and clicked "save", all traffic in/out of the LAN port stopped and I lost access to the router. I had to physically shut down the device via the console, and upon boot, the new VLAN was available and I was able to complete setting up the IP addresses, DHCP, etc for that VLAN. This happened every time I added a VLAN.

7

20.7 Legacy Series / Re: Force redirect DNS to pihole

« on: August 30, 2020, 05:48:09 pm »

I have this working with 20.1.9_1, followed the steps listed below:

https://www.reddit.com/r/OPNsenseFirewall/comments/97vikk/opnsense_and_pihole_a_guide_to_obscuring_your_dns/

Most of the guides on the internet, such as the one you are linking to, are blocking Dns queries from clients that try to get around the pihole. We're redirecting the dns queries to the pihole via NAT.

8

20.7 Legacy Series / Re: Force redirect DNS to pihole

« on: August 29, 2020, 10:37:56 pm »

i did the same as mg82, created a vlan pure for pi-hole.
those vlans cant talk to each other, only the redirect allow dns traffic to pihole: (see attachment)
then a create under NAT: port forward, for every interface that need to use pi-hole a rule (see attachment)
The rule it self is elso in the attachment.
i didn't touch anything in NAT and DHCP, those are Default.
Pi-hole itself use unbound.

Thank you! Do you have destination/invert checked for the port 53 redirect NAT rules? You are explicitly blocking all traffic from the pihole to the LANs with no exceptions, so I assume that the NAT destination/invert rule takes care of that and that it is is higher up in the order that the rules get processed. Otherwise, I can't see how the clients get their DNS responses back.
Did I get that right?

9

20.7 Legacy Series / Re: Force redirect DNS to pihole

« on: August 28, 2020, 08:14:27 pm »

My spouse and I work from home and are both on calls at night fairly often, and kids are school-from-home, so I have had very few opportunities to mess with the router. I'll have some opportunities over the weekend and will try a couple of these approaches. I'll try mg82's cute NAT+ VLAN-based approach and AhnHEL's purely NAT-based one.

I think I understand both approaches, except for one thing in ahnHEL's. Why does that approach need global auto NAT reflection? I think that is a workaround because of this part:

3.  Go to Firewall/Rules/LAN and create a firewall rule to PASS from your PiHole to the LAN ADDRESS on port 53 and place it below the above Associated Filter Rule.

        PROTO        SOURCE      PORT    DESTINATION       PORT

>    TCP/UDP      PIHOLE IP     ANY     LAN ADDRESS     53(DNS)

I think the "below" is a mistake, and the rule will never actually fire because any port 53 traffic from the pihole to another LAN IP (as it is trying to respond to a DNS query) will get blocked by the the rule above it outlined in step 2:

2. Go to Firewall/NAT/Port Forward and setup rule like below.

           INT      PROTO         SOURCE      PORT    DESTINATION       PORT              NAT IP           NAT PORT

 <->    LAN    TCP/UDP          ANY          ANY    !LAN ADDRESS     53(DNS)        (PIHOLE IP)        53(DNS)
                                                                                                                     172.16.1.5

Be sure to create the Associated Filter Rule with the above Port Forward and place it at the top of your LAN Rules.

You probably want to "PASS" DNS traffic going from the pihole to any valid interface including the router itself or even directly to the WAN gateway if your pihole is exclusively managing DNS for your networks. You want to pass port 53 to LAN or LAN/WAN before it hits that NAT rule, right? In that case:

>    TCP/UDP      PIHOLE IP     ANY     LAN ADDRESS     53(DNS)

needs to be ABOVE:

<->    LAN    TCP/UDP          ANY          ANY    !LAN ADDRESS     53(DNS)        (PIHOLE IP)        53(DNS)

right?
Then you won't need to set up a global NAT Reflection that affects all of your NAT rules, and not just this one.

I may be off base with this - thoughts?

10

20.7 Legacy Series / Re: No temperature data on Thermal Sensor widget after upgrade to 20.7.1

« on: August 27, 2020, 08:46:10 pm »

Thanks Xelas, question is, why is there junk in there to start with. Might be a 12.1 issue that needs to be resolved, but that call before any other calls using sysctl would be a good idea

If you are parsing sysctl output, then you can never be sure that kern.msgbuf does not contain a string that won't trip your parser. IMHO, unless that info is truly useful for crash diagnosis, I'd clear it with a "sysctl kern.msgbuf_clear=1" before parsing it.

In any case, looks like you got it. I just wanted to get this thought out of my head. :-)
You guys are doing an amazing job staying on top of all of the issues and bugs. OPNsense is a very complicated project!

11

20.7 Legacy Series / Re: No temperature data on Thermal Sensor widget after upgrade to 20.7.1

« on: August 27, 2020, 09:53:30 am »

From what I can tell, the last few KB from dmesg get saved in there whenever there is a system crash to aid in debugging, and this has been the behavior of FreeBSD since at least 9.0 Why this has suddenly become an issue now is mystery. Perhaps we were lucky and nothing containing the text "temperature" made it in there before to break the widget. Who knows.

I found this article from 2011 explaining how to clear kern.msgbuf:
https://www.gnutoolbox.com/clearing-dmesg-logs/

12

20.7 Legacy Series / Re: No temperature data on Thermal Sensor widget after upgrade to 20.7.1

« on: August 27, 2020, 09:24:17 am »

running:

Code: [Select]

sysctl kern.msgbuf_clear=1... on the shell/console clears it, and the temperatures INSTANTLY start showing up on the dashboard.

13

20.7 Legacy Series / Re: freeradius does not start with DHCP enabled.

« on: August 27, 2020, 06:15:31 am »

Seems to crash at startup while looking for pool name. freeradius can work as a DHCP relay, or you need to set up config files for it to work and you need to set it up with a SQL DB. The pool name it is looking for is the config for the DHCP pool.
I notice you have SQLite unchecked in your config?
See:
https://networkradius.com/doc/3.0.10/raddb/mods-available/sqlippool.html

14

20.7 Legacy Series / Re: Force redirect DNS to pihole

« on: August 27, 2020, 04:54:06 am »

Then I added a forward NAT:
Interface: LAN
Protocol: TCP/UDP
Source LAN address
Source port range: DNS
Destination / Invert: Checked
Destination:172.16.1.5/32
Destination Port: DNS
Redirect target IP: 172.16.1.5
Redirect target port: DNS
NAT reflection: Disable

I think for SOURCE you would want LAN NET not LAN Address.  But I find that if you do that then the PiHOLE itself will be included in the Port Forward and cause DNS to fail.  So I used the Invert feature and setup my Port Forward like this

INT      PROTO         SOURCE      PORT    DESTINATION       PORT              NAT IP           NAT PORT

LAN    TCP/UDP     !172.16.1.5    ANY       !172.16.1.5       53(DNS)        172.16.1.5        53(DNS)

That rule makes a ton of sense, thank you! It also looks like it eliminates needing to have another rule ahead of it to handle the pihole as a special case, so it kills 2 birds with 2 stone. Elegant.
I'll give this a shot tonight or tomorrow night after my family shuts down. Don't want to clobber precious Netflix time :-)

15

20.7 Legacy Series / Re: Force redirect DNS to pihole

« on: August 27, 2020, 04:50:02 am »

...
Source port should be ANY, not DNS (destination is DNS).  You'll also need a second rule for ipv6 if you're using ipv6.  For ipv6, use the link-local address on the pihole as that won't change.  Not sure you need that first rule.

Why would the source port be "any"? Won't that have the effect of routing all traffic on all ports to the pihole on port 53?

Frontier FIOS doesn't have IPV6, so I'm not worrying about that yet. I have IPV6 turned off for now.