@viragomann Game server is on Interface 2, Client is on the OpenVPN interface. Here's a quick layout of my network:

Interface 0 - WAN
Interface 1 - 192.168.0.x
Interface 2 - 192.168.1.x
OpenVPN - 192.168.2.x

Interface 1 an 2 can reach the internet through WAN/Interface 0, but generally can't talk to each other (with some exceptions made in the firewall).

Locally, a computer on Interface 1 can play games with computers on Interface 2. I just looked for the ports that were requested and opened those up on the firewall. Additionally, computers on Interface 2 can talk to a file share on Interface 1.

Using the VPN, I copied the rules used for the file share and gaming (on both the physical and OpenVPN interface respectively) to do the same thing for OpenVPN clients. I'm able to connect in, and from the OpenVPN client I can connect to the file share on Interface 1. I'm able to ping the game server on Interface 2, but when I try to run the games they server isn't visible in the game.

@maar said in The OVPN client can't reach the local network after successfully establishing:

You added a static route on pfSense with its own LAN IP as gateway??
That makes no sense at all. Moreover there should be set static routes for remote networks which are reachable via VPN.

Without that static route, traceroute to some-server under 10.0.10.10 (AWS) leads to nothing and I can't ping it from PFSense server at all.

But it should work from the OVH network, I assume.

That static route can bring some miss-routing into your network at all. Maybe the access from OpenVPN clients to AWS works if you remove it.

Some workers from AWS kubernetes are working with OVH databases through this tunnel from yesterday without interruptions.

This doesn't say anything about the tunnel 172.16.0.0/24 <> 10.0.0.0/16. You have three tunnels, each connects one local subnets with one on the remote site. All three have to be established for full function.

Update: It looks like this is a DNS issue. For some reason my computer wasn't using 192.168.1.1 as its DNS Server. I forced it to be this in the Ethernet settings, and is currently working fine.

@ssbarnea I have the same question with a twist. I created 9 OpenVPN clients to different geographical regions and they are in a gateway group for load balancing and failover.

Each region sends down different DNS addresses.

I also have two networks. All users connecting to LAN go via OpenVPN while users connecting to OPT1 network bypass VPN.

How do I make users on the LAN to only use OpenVPN provided DNS servers, preferably on the OpenVPN client they are currently using. Currently it appears that those clients use all DNS servers configured in General Setup.

Thanks

@tomhbp
I'm running an SSL/TLS peer to peer and this is selectable in the CSO.

However, basically I'd use a separate server for each site2site connection. But it's also possible with an access server as described here: https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-multi-purpose.html

They forwarded 1194 from the static IP to the private ip and I used ddns and everything is working now. Thanks for the tips!

@dholub
Unfortunately, no. Everything I've pulled up on both the "up" and "route-up" directives references info on running a script of some sort.

Have you found anything?

@viragomann

Thanks for this explanation. I was having similar challenges and checking "Don't Pull Routes" fixed my issue.

@emtechsg

The trick to route the packets correctly is on the pfSense at at the web servers site (83.82.88.1).
If it is on version 2.5.1 update it to 2.5.2.

If you didn't already, assign an interface to the OpenVPN instance and activate it.
This gives you a new tab in the firewall rules. Add a rule to this allowing the incoming traffic from the remote site.

Ensure that there is no rule on the OpenVPN tab matching to this traffic. If possible remove all rules if you don't need them for other OpenVPN instances.
Also ensure that no floating rule is matching that traffic.

On the other side simply port forward the traffic to the web server.

I've found that if I redirect all traffic through the VPN, traffic works normally across the VPN.

I used the following in the server config.
push "redirect-gateway def1"

So is this a client issue?

Route print on the client shows the local networks correctly in the clients routing table when I push "route x.x.x.x x.x.x.x"

But no traffic will traverse when when I push route. It only works when I push "redirect-gateway def1"

@shetu said in How to split openvpn config file:

When Grand stream connect openvpn, I can not browse GS web gui.

I have seen many GrandStream devices, for example my ATA stuff is GS HT802.
(I don't know yours specifically, but I guess the philosophy is the same)

There is a separate MGMT interface configuration option, maybe to use when OVPN is configured.

c606c79c-bfa1-497c-ab67-2c0bda60dabb-image.png

@viragomann Yup, that was it! Thanks! Now everything seems to work as it should. :D

@chrisjmuk

I get the impression you're heading in the wrong direction. With IPv6, most ISPs provide multiple /64s. I get /56, which contains 256 /64s from mine. I then assign a /64 to wherever I have a network. For example, I have 1 each for my main LAN, guest WiFi, test LAN, Cisco router and OpenVPN. I suspect you're still thinking in terms of IPv4, where is was necessary to use a hack, NAT, to make up for the address shortage. No need for that nonsense on IPv6.

@mmarco
If you set up a site2site OpenVPN select "peer to peer" server mode and use a /30 tunnel subnet.
So there is no need for a CSO.

I changed the option "Certificate Depth" from
"One (Client+Server)"
to
"Do not check"
and now I do not experience the issue anymore.

My question stays the same though:
Why is this happening on the SG-2100 and not on a virtual pfSense?

@issuehaver
Thanks for the feedback. Glad that you get it working at last.