Netgate SG-1000 microFirewall

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.

Messages - strangegopher

Pages: [1] 2 3
It works now thanks!


First off I am able to connect and get access to resources on local network and I did not have this issue before upgrading to development snapshots.

I might have messed up the setup when I setup openvpn as a client too with manual outbound NAT, but that only affects one out of 3 VLAN network. And the VLAN network I am accessing via openvpn server remains untouched by me.

So the issue I am having is that I am able to connect and get access to all my local resources but when I do whatismyip in google, I don't get my home IP, instead I get the regular non-VPN IP that I am connecting from. (IP does not change)

I have no idea how I am able to access all my local resources but don't get the local ip address.

General Questions / Re: traceroute not working on linux
« on: January 04, 2018, 05:31:13 pm »
You don't happen to do something strange and created a rule which blocks ICMP?

Not really.

It seems like issue with my laptop itself. I ran a kali virtual machine in bridge mode and did traceroute after restarting my router and switch and this is the output I got:
Code: [Select]
traceroute to (, 30 hops max, 60 byte packets
 1  router.localdomain (  1.530 ms  1.554 ms  1.352 ms
 2 (  10.761 ms  11.280 ms  11.200 ms
 3 (  12.107 ms  13.464 ms  13.210 ms
 4 (  11.823 ms  11.853 ms  11.947 ms
 5 (  16.103 ms  15.877 ms  15.292 ms
 6 (  15.234 ms  23.681 ms  23.065 ms
 7 (  15.443 ms  13.555 ms  14.085 ms
 8 (  15.090 ms  14.616 ms  14.334 ms
 9 (  68.960 ms  69.847 ms  69.734 ms
10 (  68.540 ms  68.651 ms  68.225 ms
11 (  69.721 ms  69.580 ms  69.706 ms
12 (  70.258 ms  70.256 ms  70.179 ms
13 (  71.356 ms  70.911 ms  70.650 ms
14 (  108.362 ms  68.683 ms  69.740 ms
15 (  74.016 ms  74.125 ms  73.893 ms
16 (  74.712 ms  74.664 ms  74.575 ms
17 (  74.558 ms  75.646 ms  75.351 ms
18 (  74.534 ms  74.582 ms  74.567 ms
19 (  75.680 ms  74.804 ms  75.559 ms

Not sure why its only giving me one ip address. But local ip address traceroute does not work at all.
I get proper output when I do traceroute on pfsense itself.

General Questions / traceroute not working on linux
« on: January 04, 2018, 04:01:39 pm »
traceroute does not work. the output is like this:

Code: [Select]
traceroute to (, 30 hops max, 52 byte packets
1  * * *
2  * * *
3  * * *
4  * * *

Any idea why? It was working fine few days ago but now does not work.
I am able to traceroute directly on pfsense but I can't do traceroute from my laptop to any device inside or outside my network.

edit: traceroute with tcp (-T) and icmp (-I) works but only gives one hop. but traceroute with udp (-U)/default does not work.
edit2: I disabled firewall on my laptop with no success.

Wireless / Re: Multiple VLANs with ubiquity Unifi AP
« on: December 25, 2017, 09:15:48 pm »
is your controller on trunk port too? it should be.
Also Switch -> AP port, pfSense -> switch port need to be on trunk ports.
Do you have a management wireless ssid with no vlan?
Do that and you can connect to no vlan ssid and manage AP wirelessly.

DHCP and DNS / Quad9 and DNS-over-TLS
« on: December 13, 2017, 11:28:57 pm »

I just did some quick google search and saw Quad9 supports DNS-over-TLS.

I saw config file for unbound:

But on the forums I found different config files.

Which one is correct?

I wonder why inline mode don't block anything. My guess is all rules are alert only by default and alerts only get blocked in legacy mode.

Traffic Shaping / Re: playing with fq_codel in 2.4
« on: November 21, 2017, 07:46:48 pm »
I figured I'd share my config as I spent some time today with little to do at work on converting over to fq_codel setup for my pfSense setup. I have a 1Gig Verizon FIOS line coming in which is rated at 940 down and 880 up. I have a pretty straight forward setup going as I only split up into 3 queues and basically high prioritize my games and VOIP to high and lower all my p2p / plex download traffic to everything else.

I have the Shell Command to create the proper queue setup:

I have an upload and download limiters with 3 buckets at 880Mb/s and 940Mb/s respectively. In those queues, I have a high, default and low at a 75, 25, 5 weight.

Source and Destination in the config gets a little squirrelly for me as I want to make sure I have a clear break in my upload and download traffic so I didn't select either there as I handle that in the rules config.

I have a series of match floating rules with logging setup so I can validate. All shaping is selected on my WAN interface:

My rules examples are a bit big so I linked them a little different:

Default queue

Low priority rule

For floating rules and pipes, the in and out are switched as noted in the help text. I did check that in my speed test as I can see the speeds are exactly what I expected. I noticed much better performance when compared with the other schedules stock in pfSense.

My speedtest results made me happy:

Edit 1: I seem to have a slight problem with matching my internal (Private) IPs properly. I've gotta do a little more testing to figure out why they aren't matching. My WAN rules work perfect though so it's a start. I just want to make sure I can get internal stuff matched as well.

Are you sure you need both in and out direction floating rules? Mine seems to work with just outbound floating rule.

Traffic Shaping / Re: playing with fq_codel in 2.4
« on: November 11, 2017, 08:03:21 pm »
This has to be the best thread on the forum right now. Helped me a lot.

My answer to the question for those TCP rules is the same as it was for the previous UDP rules.  What is the point?  The firewall will drop all unsolicited TCP packets as well.  I just didn't state that in my earlier response since we were specifically just talking UDP, but pfSense out of the box drops all unsolicited inbound traffic on the WAN.

If you don't open a port and specify a protocol in a firewall rule, then nothing gets in.  So if you don't have an explicit firewall rule allowing MS-SQL inbound (TCP port 1433), then nothing can connect to that port.  Putting a MS-SQL drop rule in Suricata does not accomplish much in my view.  Instead of having Suricata munch through a bunch of rules to drop traffic the firewall is going to block anyway, I would reserve Suricata's processing to protect stuff where I have actual vulnerabilities (such as rules looking for local clients attempting communication with known malware BOT nets, various JavaScript or PDF attacks from web sites, etc.).


Thanks for clarification.

What is the point of this custom rule?  The firewall will, with its default configuration, drop all unsolicited inbound UDP traffic anyway.  Having this custom DROP rule on an interface is not useful and can in fact cause a lot of trouble (as you are apparently experiencing).  Change this rule to ALERT instead of DROP and then check how many alerts it generates.  It is going to block stuff you need to have working (like DNS for one thing).  See, Suricata is not "stateful" like the firewall, so it can't understand that a query went out on say UDP port 53 for a DNS lookup so we will let the reply come back in.  Suricata will just look at the port number and protocol and drop the traffic if they match with no regard for any previously established states.


Thank you for explaining the issue to me.

What about following rules:
Code: [Select]
drop tcp $EXTERNAL_NET [0:1023] -> $HOME_NET [0:1023](msg:"Golden Rule BAD TCP"; classtype:attempted-recon; sid:9900001; rev:1;)
drop udp $EXTERNAL_NET [0:1023] -> $HOME_NET [0:1023] (msg:"Golden Rule BAD UDP"; classtype:attempted-recon; sid:9900002; rev:1;)

Code: [Select]
drop tcp $EXTERNAL_NET any -> $HOME_NET [0:1023,![25,443,465,993]] (msg:"Golden Rule NO SERVER TCP"; classtype:network-scan; sid:9900004; rev:2;)

Code: [Select]
drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [3389] (msg:"Admin Rule NO SERVER RDP TCP"; classtype:network-scan; sid:990050; rev:1;)
drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [5500] (msg:"Admin Rule NO SERVER VNC TCP"; classtype:network-scan; sid:990052; rev:1;)
drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [5800] (msg:"Admin Rule NO SERVER VNC TCP"; classtype:network-scan; sid:990053; rev:1;)
drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [5900] (msg:"Admin Rule NO SERVER VNC TCP"; classtype:network-scan; sid:990054; rev:1;)
drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [4899] (msg:"Admin Rule NO SERVER RADMIN TCP"; classtype:network-scan; sid:990055; rev:1;)
drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [1433] (msg:"Admin Rule NO SERVER MSSQL TCP"; classtype:network-scan; sid:990057; rev:1;)
drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [5060] (msg:"Admin Rule NO SERVER SIP TCP"; classtype:network-scan; sid:990059; rev:1;)
drop udp $EXTERNAL_NET [1024:65535] -> $HOME_NET [5060] (msg:"Admin Rule NO SERVER SIP UDP"; classtype:attempted-recon; sid:9900060; rev:1;)
drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [8172] (msg:"Admin Rule NO SERVER IIS TCP"; classtype:network-scan; sid:990061; rev:1;)
drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [31337] (msg:"Admin Rule NO SERVER Back Orifice TCP"; classtype:network-scan; sid:990063; rev:1;)
drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [47001] (msg:"Admin Rule NO SERVER WinRM TCP"; classtype:network-scan; sid:990064; rev:1;)

line will drop all UDP traffic that come to your external IP on low ports ( use it if you don't have a server listening for that traffic )

Code: [Select]
drop udp $EXTERNAL_NET any -> $HOME_NET [0:1023] (msg:"Golden Rule NO SERVER UDP"; classtype:network-scan; sid:9900003; rev:1;)

I don't have any server listening on any udp port from 0 to 1023. But when I do live rule update (or even regular rule update) at midnight, the only rule that gets flagged in alerts tab (not blocked) is the rule above every few seconds and only way to fix it is a full restart.

The dns port gets flagged with source being and destination being my ip address.

2.4 Development Snapshots / Re: Two Error Messages
« on: October 25, 2017, 09:28:33 pm »
Made a little fix to retry the command when pf is apparently 'busy' processing commands from another program:

It seems to be related to this issue reported on FreeBSD 10.4 where also a 'retry' is advised as the proper thing to do.

Still probably ignoring the 'messages' doesn't hurt, but the actions taken by code will now hopefully be a bit more 'clean' once the PR is pulled.

Great detective work there. I hope to see the fix soon.

Pages: [1] 2 3