In the firewall logs you only you the origin source IP, that's the VPN clients IP.
You can do a packet capture (in Diagnostic menu) on LAN interface. There you will see the translated address.

I know site 2 site must define remote side lan networks

Technically this statement is true, but that's not what I said to do.  I said the remote sites need to define the tunnel network of HQ's remote access server

I'm using public IP(4g) remote access connect to HQ

I'm not sure why this matters.  Please provide a network map and elaborate.

Better try to draw a diagram with you hw config maybe I understand something wrong with what you want to achieve…

The OP hasn't posted his config and responded in 5 days.  I guess we'll assume he figured it out.

Hi,

I have a similiar configuration and have reconfigured my OpenVPN a few days ago according to this document : https://doc.pfsense.org/index.php/Multi-WAN_OpenVPN.
It seems to be working. If I disconnect my first WAN connection on the OpenVPN Server side, the Client reconnects after a short time via the second link.
If the first link is back up, when I disconnect the second link, the client switches back to the first link.

With this configuration the client side won't reconnect automaticaly if the primary gets back online again..it stays on the second connection as long as it is available or until you reconnect the client side, but this is exactly how I want it to work.

The client is working just fine. I can't access my vpn server through the client interface.

But you mean that it could be issues with sending tls packages within the client interface to my own vpn server?

Still don't get why the traffic goes over random ports.. If I only could get it to use specific ports..

@networknut:

Have you tried the connection by hostname and by the clients VPN IP to find out if the problem is the NetBIOS?

Yes I have

So it doesn't work in both ways?

@networknut:

I did a trick on my VPN server: I push the default route to the clients, but with a high metric, so it doesn't override the clients default route. So if windows has configured a gateway for an network interface it handles the connection as reliable.

Can you be so kind as to provide an example of how you went about doing that?

In the server advanced configuration section > custom options field I entered

However, the metric option entered here is also applied for any route, which are pushed to the clients, but no matter since there is no other route for this destination on the client with lower metric. So the route option could as well be set by entering "0.0.0.0/0" in the Locale Network(s) field above.

Are you running the wireless from PFSense or a wifi router?

If using wifi from PFSense I am not sure, however I just setup a second network to do exactly what you want to do! It is wired though, would just need to add a wifi router.

@Derelict:

Hmm. I have never had to reboot to get a change like that to take effect. Might have more to do with clearing existing states.

Yeah I would have thought it didn't need one! But hey it works so all good.

My solution was 1) reinstall pfSense 2.24, 2) observe browsing and website response, 3) allow program to download and install current version. Repeat Step 2. Install security update 2.3.1_1. Repeat Step 2. PIA was configured per guide and modified instructions. Repeat Step 2.

I can't describe it yet browsing 'feels' normal before upgrade to 2.3.

Initial upgrade to 2.3.1 from 2.2.6 failed. IIRC it required 3 attempts. I didn't realize it but there were big changes to 2.3 from 2.2.x.

IMO OpenVPN issues were triggered by incremental updates did not properly address PHP.

Suggest reinstalling previous pfSense without configuring OpenVPN. Allow program to download and install current version, install security update(s), and configure OpenVPN.

Hope this helps.

My solution was 1) reinstall pfSense 2.24, 2) observe browsing and website response, 3) allow program to download and install current version. Repeat Step 2. Install security update 2.3.1_1. Repeat Step 2. PIA was configured per guide and modified instructions. Repeat Step 2.

I can't describe it yet browsing 'feels' normal before upgrade to 2.3.

Initial upgrade to 2.3.1 from 2.2.6 failed. IIRC it required 3 attempts. I didn't realize it but there were big changes to 2.3 from 2.2.x.

IMO OpenVPN issues were triggered by PHP. Incremental updates did not properly address PHP.

Suggest reinstalling previous pfSense without configuring OpenVPN. Allow program to download and install current version, install security update(s), and configure OpenVPN.

Hope this helps.

@Derelict:

You could also try adding an IP alias VIP to Localhost on an IP network distinct from your LAN and include that address/network in the Local Networks of the OpenVPN Server. In the unlikely event you experience a subnet collision with LAN, you could connect to the localhost VIP instead. Less heavy-handed than redirecting all traffic through the tunnel if that's not what you want.

Thank you for the reply/suggestions,

Yes this situation has previously happened; I was told I could access my WAN DDNS link from anywhere so long as I make the correct rules in my firewall (for my VPN connections exclusively of course). I tried the VIP as such.

1.Selected IP Alias for the type
2. For interface I selected Localhost
3. Address type only allowed me to use Single address
4. I input my OpenVPN address for the Address section
5. Left Virtual Ip Password, VHID Group, Advertising frequency, and Skew blank/at defaults

My connections can now access my hostname + domain link url to my pfSense box (previously wasn't able to); but I cannot put my DDNS link into the VIP, or access it still from its url. Can you guide me on your suggestion?

The OS routes in the routing table are not from iroutes, they are from the "remote network" definition or "route" statements in the OpenVPN server.

If you want to move a site-to-site client from one VPN to another you have to change the override to the other server (if it was set to use just the old server anyhow) and you have to change the route/remote networks on the old and new server.