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 - marvosa

Pages: [1] 2 3 4 5 ... 52
OpenVPN / Re: OpenVPN only as "Peer-to-Peer" for my NAS
« on: Today at 09:25:59 pm »
Please restate what you're trying to do.

General Questions / Re: DNS Forwarder not working on reboot
« on: Today at 01:11:41 pm »
Several upgrades ago, I had a similar issue with the forwarder... where it would not resolve anything after an upgrade.    I never tried re-saving the config, but what did work for me was specifically selecting my LAN interfaces on Services -> DNS Forwarder instead of leaving it on "All".

We may have two totally separate issues, but it's worth a shot.

OpenVPN / Re: little bit lost
« on: Today at 09:17:23 am »
Is the NAT an issue? the link establishes successfully.
As long as you have your local port forwarded to PFsense, you should be fine, but I have read on other forums that if everything appears to be configured correctly and still doesn't work that you may have to create a static route on your edge router for the tunnel network.  However, that may have been limited to remote access configs... I just don't remember.  At any rate, it's moot since you're up and running.

nopull was added because it turned the client pfsense into a black hole, necesary for me to post here. perhaps i should have mentioned! but fixing route ip has solved this, thanks again.
This is an explanation of the route-nopull directive from the OpenVPN manpage:
"When used on the client, this option effectively bars the server from adding routes to the client's routing table, however note that this option still allows the server to set the TCP/IP properties of the client's TUN/TAP interface."

My assumption is your setup is working because you've defined a remote network on the client-side.  Otherwise, the client would deny pushed routes and there would be no routing to the server-side LAN over the tunnel. 

i don't understand the requirement of CSO, the route exists in the route table already, ->
I could be wrong, but my guess is things are working because there's only 1 tunnel and 1 peer, so there's no where else for the traffic to go.  However, imagine if there were 8 tunnels... how would the system know which peer to send each respective LAN traffic to?  Per the wiki, that's where the CSO tab comes in.

Skimming over the wiki ->, it looks like a typical setup is not to define much of anything on the client-side and control everything from the server.  In which case, configuring CSO options per tunnel would be necessary.

OpenVPN / Re: little bit lost
« on: February 17, 2018, 09:31:10 pm »
Are you using a PKI or Shared Key setup?

I can see you're double NAT'd on both sides, which is an extra complication in and of itself.  You may end up needing static routes on your edge routers.

  • Quote
    push "route"
    This line is incorrect on your server config.  This line should read -> push "route".  Which tells me you're probably running a PKI setup and entered your network wrong on the IPv4 Local network(s) line.  It's should be     
  • Quote
    This line is also incorrect on your server config.  This line should read -> route  Go to the IPv4 Remote network(s) line on your server config and enter
  • Quote
    The client-side has Don't add/remove routes checked in the client config.  Which means the client is denying routes pushed from the server.  I'm not sure how this was expected to work given your setup.

In addition to the corrections above, if you're using a PKI setup, you'll need an iroute statement on your CSO tab so the server knows that is behind your client's specific peer address

Honestly, unless you're planning on scaling to 7+ tunnels, I'd recommend moving to a shared key setup.

OpenVPN / Re: little bit lost
« on: February 15, 2018, 08:23:20 pm »
Post the server1.conf from the server and the client1.conf from the client.

OpenVPN / Re: Minor issue - Changing WAN IP breaks OpenVPN until restart
« on: February 14, 2018, 03:19:41 pm »
There is the --float directive.
See manual 2.4:

How that is handled by pfSense firewall. i do not know, just try it.

As I read about the float directive, it appears to deal with incoming connections from clients and does not address updating the IP that the OpenVPN service is bound to after a WAN IP change on PFsense.    E.g. if a client is on a laptop connected to a flaky cellular hotsot and the connection breaks briefly causing the hotspot to reconnect and acquires a new public IP ... the float directive will allow the client to re-connect and authenticate even though subsequent connections (post reconnect) are coming from a different IP than the initial connection. 

OpenVPN / Re: Minor issue - Changing WAN IP breaks OpenVPN until restart
« on: February 14, 2018, 01:25:28 pm »
Yes, you can look at two things:
  • In your OpenVPN config, you will see a line stating:
    • Local (wan_ip) - Which shows the IP that the service was bound to when the OpenVPN service started
  • Run "sockstat -4 -l" from the shell.  Which will show you what IP, port, and protocol the openvpn service is currently listening on
Neither of the above is going to update until the OpenVPN service is restarted.  So, there currently must not be a mechanism to restart the OpenVPN service once an IP change has been detected on the WAN interface. If it's something that happens frequently on your connection,  I would submit an enhancement or feature request.  Unfortunately, I am not sure how that would be submitted.  Possibly thru the bug tracker ->

General Questions / Re: New to PFSense. Need Help ..
« on: February 14, 2018, 06:54:47 am »
My question is, when setting up the wizard after the first log in Via. the GUI were do I start. Do I enter my ISPs DNS for example in the wizard or something like Google's , or even my VPN providers.
It all depends on what you're trying to do, but assuming you have a typical home setup, you shouldn't need to enter anything for DNS, it will be provided via DHCP from your ISP.

I have managed too assign an IP Address to the Local LAN but I'm unsure how to connect the actual WAN, as I'm not sure if I should connect the WAN too the Switch I have or have that connection running from my ISP Router \ Modem.
PFsense allows all outgoing traffic by default, so once the LAN IP is assigned and DHCP is activated, it should all just work.  A typical home setup is:

ISP Modem (in bridge mode) ----> (WAN interface) PFsense (LAN interface) ----> Switch

I'm trying to get online after routing my Ethernet connection threw WAN and having no luck. I'm having too directly connect to the Switch to get access.
Once connected like I've shown above, all of your devices should be connected to the switch.  At this point, your devices will be getting their configuration via DHCP and will be using the PFsense LAN IP as the default gateway and DNS... and should be online.

General Questions / Re: Cross subnet access problem
« on: February 13, 2018, 04:22:05 pm »
We will need a network map to offer any targeted troubleshooting, but I suspect you have a networking issue.

What you should have is each NIC connected to a separate vSwitch and then physically connected to either separate unmanaged switches or connected to a managed switch configured with VLAN's.

If you have your NIC's connected to the same switch (either physically or virtually), it's not going to work.

General Questions / Re: How To Remotely Access Router WebGUI ?
« on: February 12, 2018, 08:04:48 pm »
Thanks for the advice. As I'm the only user I can set it to whatever. So a higher port like 5xxxx or suchlike would be less likely to attract attention? ?
Something random, yes, 5xxxx works... it can be anything really... I would just make it random that isn't commonly known as an admin port

Second question, I noted your reply a couple posts above... what's the advantage of a port forward from 5xxxx > 443 vs just using 5xxxx in System/Advanced/Admin Access? Simply so you can continue to use 443 internally on LAN? Or something else?
1)IMO, it's just one more hurdle for someone to go over...the real port isn't exposed, so the port/service first has to be discovered for a connection attempted to be made.  Hopefully, you have IDS/IPS catching port scans, etc.  Is there an advantage over changing the TCP port to e.g. 56832 and then mapping directly to 56832?  The only real advantage would be the option of keeping everything on the backend on "normal" ports... instead of having to make changes on the backend to match the frontend.

I guess if you only want to access from some fixed locations that would work, but if you want to access from a roaming laptop or mobile device on 4g, that wouldn't be possible.....
The simple solution, which is what I've done:
  • Open a free Dynamic DNS account (e.g.
  • Create an alias on PFsense with as the FQDN
  • Have the client update software running on your laptop, so your IP is always updated
  • Have your firewall rule sourced from the alias you just made
Now, not only do you have access from whatever IP is currently updated with, but you can also add multiple hosts to the same alias for access... e.g. home, work, etc... all from one firewall rule and it's still explicit.

General Questions / Re: How To Remotely Access Router WebGUI ?
« on: February 11, 2018, 01:26:17 pm »
The solution occamsrazor's provided works too.  Although, 8080 is a known admin port for many devices and applications, so I personally wouldn't open 8080 if I had other options.  Also, I would not leave the source as "any".  I would configure the source with an explicit list of the IP's you want accessing the firewall.

General Questions / Re: How To Remotely Access Router WebGUI ?
« on: February 11, 2018, 12:42:05 pm »
Agreed. Configuring VPN access is the ideal solution.  However, another option is configuring a port forward on a random port then redirect it to the firewall's LAN IP on port 443.  The last step would be to enter your home public IP as the source so the rule is explicit and only you can access the rule from the outside.

OpenVPN / Re: DHCP clients on LAN do not see OpenVPN network
« on: February 10, 2018, 12:27:35 pm »
What is the LAN subnet on both sides?

OpenVPN / Re: OpenVPN Site to Site Issue
« on: February 10, 2018, 09:25:18 am »
Post the server1.conf from the server and the client1.conf from the client, so we can offer a targeted troubleshooting effort.

I see one issue right off the bat:

I have set "IPv4 Remote Network(s)" on both client and server to use the same IP network.

In a routed solution, all LAN subnets have to be unique and non-overlapping... i.e. the server-side LAN has to be different than the client-side LAN, which should be reflected accordingly in the IPv4 Remote network(s) box on both sides.

OpenVPN / Re: DHCP clients on LAN do not see OpenVPN network
« on: February 10, 2018, 08:49:34 am »
Are you seeing blocks in the logs?  Would need to see the config on both sides to offer any targetted help.  Post the server1.conf from the server and the client1.conf from the client.

Pages: [1] 2 3 4 5 ... 52