1
20.1 Legacy Series / Re: Unknown Log Entries
« on: April 29, 2020, 10:42:17 pm »
Thanks for the response. I am running 20.1.5. thought I may have changed a setting of some sort. I'll just wait for the patch in the updated release
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.
Pages: [1]
2
20.1 Legacy Series / Unknown Log Entries
« on: April 29, 2020, 09:44:33 pm »
Hello,
Today while I was looking at some logs, I found some white entries with not much details to them. I've attached a screenshot. Can anybody enlighten me as to what these entries might be?
Thanks
Today while I was looking at some logs, I found some white entries with not much details to them. I've attached a screenshot. Can anybody enlighten me as to what these entries might be?
Thanks
3
19.1 Legacy Series / Re: How to disable IPv6
« on: April 13, 2019, 02:21:50 am »
Actually that doesn't work as it should either.
When I added the rule myself as noted above, I got this: ipv6_01.png
But when I unchecked the box to allow IPv6 I got this: ipv6_02.png
I don't think you did it correctly.
You need to enable "Allow IPv6". If you uncheck it then the system will place a firewall rule at the top that will log blocked traffic.
Once you enabled that make sure your floating rule looks like the following and make sure you choose all interfaces you want to block and hide traffic from the log.
4
19.1 Legacy Series / Re: How to disable IPv6
« on: April 12, 2019, 12:18:06 am »
@Charles2019 see the fourth post above on how to accomplish this. You have to create a new floating rule.
5
19.1 Legacy Series / Re: How to disable IPv6
« on: April 11, 2019, 12:16:31 pm »
While I understand that disabling IPv6 should mean no IPv6 whatsoever on any interface, I was under the impression that OP's main goal was to not see the IPv6 traffic in his logs so he could better visualize his IPv4 traffic.
Also, if we don't start to utilize IPv6 and understand it then, we will always fall back to not wanting to use it. I have signed up with HE.net for a 6in4 tunnel and got a /64 and a /48 subnet of IPv6 addresses to play around with in my home lab. To me, it is a bit easier to manage IPv6 as you don't have to deal with matching FW rules to NAT rules and no port forwards. Everything is just straightforward. But some may say the opposite of this.
Also, if we don't start to utilize IPv6 and understand it then, we will always fall back to not wanting to use it. I have signed up with HE.net for a 6in4 tunnel and got a /64 and a /48 subnet of IPv6 addresses to play around with in my home lab. To me, it is a bit easier to manage IPv6 as you don't have to deal with matching FW rules to NAT rules and no port forwards. Everything is just straightforward. But some may say the opposite of this.
6
19.1 Legacy Series / Re: How to disable IPv6
« on: April 11, 2019, 03:50:01 am »
Try this:
Go to Floating Rules and create a rule with the following paremeters
Action: Block
Quick: Check "Apply the action immediately on match."
Interface: Select all interfaces to block all IPv6 traffic on the firewall.
Direction: any
TCP/IP Version: IPv6
Protocol: any
Source: any
Destination: any
Log: Uncheck "Log packets that are handled by this rule"
Description: BLOCK ALL IPv6
Save and apply. Move rule to top of the floating rules.
At this point you should have two Block IPv6 rules. The system rule "Block all IPv6 traffic" and the rule you just created which should be directly below the system rule.
Now go to Firewall -> Settings -> Advanced and enable "Allow IPv6". This will disable the system rule. Even though you are enabling IPv6 here, the rule you just created will block the traffic and not log it.
Now go back to the Floating Rules to verify that the rule you just created is now directly above every other rule. Now check your firewall logs to see if you still see IPv6 traffic in your logs. There shouldn't be any.
Test and let me know.
P.S: To check that the rule is working before setting it and leaving it, you can enable "Log packets that are handled by this rule" to verify the IPv6 traffic is falling on that rule.
Go to Floating Rules and create a rule with the following paremeters
Action: Block
Quick: Check "Apply the action immediately on match."
Interface: Select all interfaces to block all IPv6 traffic on the firewall.
Direction: any
TCP/IP Version: IPv6
Protocol: any
Source: any
Destination: any
Log: Uncheck "Log packets that are handled by this rule"
Description: BLOCK ALL IPv6
Save and apply. Move rule to top of the floating rules.
At this point you should have two Block IPv6 rules. The system rule "Block all IPv6 traffic" and the rule you just created which should be directly below the system rule.
Now go to Firewall -> Settings -> Advanced and enable "Allow IPv6". This will disable the system rule. Even though you are enabling IPv6 here, the rule you just created will block the traffic and not log it.
Now go back to the Floating Rules to verify that the rule you just created is now directly above every other rule. Now check your firewall logs to see if you still see IPv6 traffic in your logs. There shouldn't be any.
Test and let me know.
P.S: To check that the rule is working before setting it and leaving it, you can enable "Log packets that are handled by this rule" to verify the IPv6 traffic is falling on that rule.
7
19.1 Legacy Series / Re: Slow bandwidth from lan to wan (OPNsense on Proxmox VE)
« on: April 10, 2019, 07:15:53 pm »
I've installed OPNSense on Proxmox as well. And have had the same trouble with WAN speeds. Have you tried bridging the WAN interface to Proxmox rather than passing the device through directly to VM? PCI Passthrough is experimental in Proxmox from what I read.
8
19.1 Legacy Series / Re: nginx 1.7: banning, even if Learning Mode on.
« on: April 03, 2019, 04:33:29 am »no, it is hardcoded in the config. You can use the plugin interface to create a similar config and disable the internal check.
https://github.com/opnsense/plugins/blob/master/www/nginx/src/opnsense/service/templates/OPNsense/Nginx/http.conf#L241
The UUID is the id you get in the config.xml and in the api for the HTTP server.
Thank you. This worked perfectly. Took me a minute to realize i had to create the UUID_pre/ folder.
Regards
9
19.1 Legacy Series / Re: DHCP responses on WAN interface
« on: April 03, 2019, 03:40:47 am »
Oh wow, our posts are literally 4 minutes apart from each other.
I am in the US using Spectrum as my provider.
I am in the US using Spectrum as my provider.
10
19.1 Legacy Series / DHCP responses on WAN interface
« on: April 02, 2019, 10:15:50 am »
Hello,
I am a new user to OPNsense and I am trying to understand some log entries on my WAN interface. I'm getting DHCP OFFER and ACKNOWLEDGE packets on my WAN interface from my cable provider's DHCP server (10.80.212.53).
I did a packet capture and viewed the data in Wireshark. What I noticed was that these OFFERs and ACKNOWLEDGEMENTS were responses to other user's (Cable Customers) DHCP DISCOVER and REQUEST messages and not mine. Each packet contains a different Client IP address and MAC address. I know that DHCP can communicate via Broadcast or Unicast. In this case, the responses from the server are being broadcasted back to the clients.
1) Is this normal to see on the WAN interface?
2) Is this traffic supposed to be allowed to the Firewall?
3) Why are the broadcasts only showing up from the server but I am not seeing client broadcasts for the DISCOVER messages?
If somebody could please help me out with these questions, it would be much appreciated.
I am a new user to OPNsense and I am trying to understand some log entries on my WAN interface. I'm getting DHCP OFFER and ACKNOWLEDGE packets on my WAN interface from my cable provider's DHCP server (10.80.212.53).
Code: [Select]
Interface Time Source Destination Proto Label
WAN Apr 2 03:51:36 10.80.212.53:67 255.255.255.255:68 udp Block private networks from WAN
WAN Apr 2 03:51:36 10.80.212.53:67 255.255.255.255:68 udp Block private networks from WAN
WAN Apr 2 03:51:16 10.80.212.53:67 255.255.255.255:68 udp Block private networks from WAN
WAN Apr 2 03:51:11 10.80.212.53:67 255.255.255.255:68 udp Block private networks from WAN
WAN Apr 2 03:51:05 10.80.212.53:67 255.255.255.255:68 udp Block private networks from WAN
WAN Apr 2 03:51:02 10.80.212.53:67 255.255.255.255:68 udp Block private networks from WAN
WAN Apr 2 03:51:00 10.80.212.53:67 255.255.255.255:68 udp Block private networks from WAN
WAN Apr 2 03:50:55 10.80.212.53:67 255.255.255.255:68 udp Block private networks from WAN
WAN Apr 2 03:50:55 10.80.212.53:67 255.255.255.255:68 udp Block private networks from WAN
WAN Apr 2 03:50:55 10.80.212.53:67 255.255.255.255:68 udp Block private networks from WAN
WAN Apr 2 03:50:46 10.80.212.53:67 255.255.255.255:68 udp Block private networks from WAN
WAN Apr 2 03:50:42 10.80.212.53:67 255.255.255.255:68 udp Block private networks from WAN
WAN Apr 2 03:50:42 10.80.212.53:67 255.255.255.255:68 udp Block private networks from WAN
WAN Apr 2 03:50:40 10.80.212.53:67 255.255.255.255:68 udp Block private networks from WAN
WAN Apr 2 03:50:37 10.80.212.53:67 255.255.255.255:68 udp Block private networks from WAN
WAN Apr 2 03:50:33 10.80.212.53:67 255.255.255.255:68 udp Block private networks from WAN
WAN Apr 2 03:50:21 10.80.212.53:67 255.255.255.255:68 udp Block private networks from WAN
WAN Apr 2 03:49:55 10.80.212.53:67 255.255.255.255:68 udp Block private networks from WAN
WAN Apr 2 03:49:53 10.80.212.53:67 255.255.255.255:68 udp Block private networks from WAN
WAN Apr 2 03:49:49 10.80.212.53:67 255.255.255.255:68 udp Block private networks from WAN
WAN Apr 2 03:49:49 10.80.212.53:67 255.255.255.255:68 udp Block private networks from WAN
WAN Apr 2 03:49:32 10.80.212.53:67 255.255.255.255:68 udp Block private networks from WAN
WAN Apr 2 03:49:09 10.80.212.53:67 255.255.255.255:68 udp Block private networks from WAN
WAN Apr 2 03:49:06 10.80.212.53:67 255.255.255.255:68 udp Block private networks from WANI did a packet capture and viewed the data in Wireshark. What I noticed was that these OFFERs and ACKNOWLEDGEMENTS were responses to other user's (Cable Customers) DHCP DISCOVER and REQUEST messages and not mine. Each packet contains a different Client IP address and MAC address. I know that DHCP can communicate via Broadcast or Unicast. In this case, the responses from the server are being broadcasted back to the clients.
1) Is this normal to see on the WAN interface?
2) Is this traffic supposed to be allowed to the Firewall?
3) Why are the broadcasts only showing up from the server but I am not seeing client broadcasts for the DISCOVER messages?
If somebody could please help me out with these questions, it would be much appreciated.
11
19.1 Legacy Series / Re: nginx 1.7: banning, even if Learning Mode on.
« on: April 02, 2019, 07:25:29 am »
I see that the included protection for bots blocks the following User-Agents:
Is it possible to edit the list of default bad bots from GUI or would I have to edit from CLI every time the nginx config is changed? I have an application that uses the User-Agent "OKhttp" and would like to just allow this user-agent rather than disabling the entire protection from GUI
Code: [Select]
Python-urllib|Nmap|python-requests|libwww-perl|MJ12bot|Jorgee|fasthttp|libwww|Telesphoreo|A6-Indexer|ltx71|okhttp|ZmEu|sqlmap|LMAO/2.0|ltx71|zgrab|Ronin/2.0|Hakai/2.0Is it possible to edit the list of default bad bots from GUI or would I have to edit from CLI every time the nginx config is changed? I have an application that uses the User-Agent "OKhttp" and would like to just allow this user-agent rather than disabling the entire protection from GUI
Pages: [1]