Netgate Store

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
Thanks for the info Marvosa!

One more question, is there a way to route all available LANs from site-to-site tunnel to Remote Access tunnel? Or pushing each LAN is a more proper way to do?
buomque, it depends on what kind of solution you want to end up with.  One way to achieve your objective is going full tunnel, but then all traffic is routed down the tunnel.  If you want to stay split tunnel, then every subnet you want access to will need to be pushed out to your clients.

If I understand your original post correctly, you appear to have a similar circumstance as mine. I have a main office in NY that is connected to an office in Atlanta via S2S VPN. Users also want to be able to remotely access their network from home and have access to files on both servers. Two questions for you:

1) Is what you described in your original post capable of doing that (that's what it looks like to me)

2) Can you elaborate on how you achieved this? I understand, conceptually, the need to push to the client, but what exactly were the steps you took?

Thanks, I know this thread is a little old, but I'm trying to figure out to route traffic such that users can connect from home and access files on servers at each office.
drummrman85, he may or may not answer, but regardless... I would start a new thread and provide specifics so we can offer targeted guidance based on the details of your network

OpenVPN / Re: Client VPN access to multiple subnets
« on: April 05, 2018, 07:21:35 am »
Hi guys,
I'm also having the same problem,
and also I tried adding push route in "Advanced Configuration". its not working.
any other suggessions ?
deepak11, this is a 4.5 year old thread, you should start a new thread with your specific details in it, so we can offer targeted troubleshooting.

At a high level, two things are needed:
  • On site A's remote access config, push a route to site B's LAN to your clients
  • On Site B's site-to-site config, add a return route to site A's remote access tunnel network
This can all be done in the GUI now

Verify you don't have any rogue traffic shaping rules or limiters.

Are you routing all traffic over the AirVPN tunnel?

Do you have a site-to-site tunnel to your friend's firewall?  I doubt this is it, but double check that your rules are not routing traffic through your friend's connection

I would need to see your OpenVPN config's and your firewall rules to offer more targeted troubleshooting.

You have a networking issue.  What are you doing with your setup?  Either create your VLAN's on PFsense and trunk it to your switch or create a transit between PFsense and your switch, enable routing and then create the VLAN's on your switch.  Trying to mix and match the two is not going to work.

OpenVPN / Re: OpenVPN only as "Peer-to-Peer" for my NAS
« on: February 20, 2018, 03:00:20 pm »
Ok, so you want to be able to VPN to your home PFsense box and access resources on your home network while traffic destined for the internet goes out the normal Work WAN.  That would be a split tunnel setup and is pretty standard and straightforward.  You shouldn't need to add any manual routes if your server is configured correctly. 

The one thing to note is that in a routed solution, all LAN subnets have to be unique throughout all connected environments.  In other words, your Home LAN subnet has to be different from your Work LAN subnet.

As far as your objective, all you have to do is uncheck the "Redirect Gateway" box under the Tunnel Settings section.

At another place like public WiFi I would like to use the same VPN Server on the pfSense for direct the entire trafic over it.
Is this possible with only change some stuf at the config file or do I have to create a second OpenVPN Server on pfSense side?

You have two options, one ideal and one less than ideal:
  • Create a separate, "Full Tunnel" OpenVPN server which listens on a different port, has a different tunnel network and has the Redirect Gateway box checked.  You'd connect to this server @ WiFi hotspots or whenever you want to bypass filtering, etc
  • You can use the same server for both situations, but you'd have to connect to the server and then toggle the Redirect Gateway box every time you want to go full tunnel.  Then uncheck it when you want to go back to split tunnel.
The most straightforward and efficient option is #1, IMO.  Option 2 sounds like a nightmare compared to just having two profiles to select from and selecting them accordingly for the appropriate situation.

OpenVPN / Re: little bit lost
« on: February 20, 2018, 08:52:48 am »
Thanks, this makes sense of course for multiple clients and cetralising configuration sounds useful.

The openvpn link is established however that was not really the issue,
I still have no connectivity between clients other than the pfsense running openvpn client -> pfsense running openvpn server.

I'm a bit confused... because in your last post you stated:
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.

Did we regress from that statement?  Was it ever working?  If you're testing with windows clients, I would disable the software firewall on both ends and re-test... to verify windows firewall is not interfering.  Then reassess what is and what is not working.

OpenVPN / Re: OpenVPN only as "Peer-to-Peer" for my NAS
« on: February 19, 2018, 09:25:59 pm »
Please restate what you're trying to do.

General Questions / Re: DNS Forwarder not working on reboot
« on: February 19, 2018, 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: February 19, 2018, 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.

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