@jasmantle So you will either need static routes for the OpenVPN network on the LAN devices pointing to the OpenVPN server to direct response packets back, or do a workaround with masqerading on pfSense. However, the masqerading (s-NAT) solution can only be recommended if the VPN is for your own purposes, but not for multiple users. You won't be able to determine the real user on the destination device.

Just tried on two test firewalls. Hint: Apply on client first , then on server. 1: I applied the fix on the client , then the server , client disconnected then reconnected and came up. 2: I applied the fix on server , then client disconnected and was "lost" I saw these on the server Oct 14 08:43:01 openvpn 10921 FRAG_IN error flags=0xfb00001d: bad fragment size Oct 14 08:43:00 openvpn 10921 FRAG_IN error flags=0xfb00001d: bad fragment size Came up after i did a HTTPS to Outside , and applied the client fix. I'd recommend to have a HTTPS access to the "Outside ip" (NON VPN based) , just in case ... Or you prob could remove the server fix , and do it in reverse order. /Bingo

@Sergio-Procopio From Google Translate: *Good afternoon everyone, I am in need of help where I have an IPSEC situation with OpenVpn. I have two company customers that use IpSec VPN. With this pandemic, our consultants are unable to access the network of these two clients via OpenVpn. I have tried to ask customers to allow my 10.10.10.0/24 network in their rules to be accessed remotely. Can anybody help me?* If those customers are using IPSec and the consultants OpenVPN, they'll never be able to connect. You need the same VPN type at both ends. It has nothing to do with the network address. Once you connect, using one VPN or the other, it's just a matter of routing and rules. The only caution is that you don't use the same network address at both ends. Se esses clientes estiverem usando IPSec e os consultores OpenVPN, eles nunca conseguirão se conectar. Você precisa do mesmo tipo de VPN em ambas as extremidades. Não tem nada a ver com o endereço de rede. Depois de se conectar, usando uma VPN ou outra, é apenas uma questão de roteamento e regras. O único cuidado é que você não use o mesmo endereço de rede nas duas extremidades.

server1.conf.txt Even though this post is 2 years old, I thought should reply to it as is still relevant today and helped me fix the same problem I had in 2020. As like the original post, I too couldn't access any local network resources while my pfSense is set up in a local XCP-ng VM using only one WAN port. I was able to access the internet and local pfSense IP but couldn't ping any other LAN IP/resources. Oddly, the local Xen Orchestra website loaded without any images, only the login page with just text but couldn't access all the other local resources, NAS, Plex server, local servers, etc. Thanks to viragomann advice on setting up the Firewall NAT Outbound rule, everything works. I was able to access all LAN resources from my work!! My router IP is 192.168.2.1 so I setup the NAT Outbound rule as followed: Interface: WAN Source: Any Destination: Network 192.168.2.0/24 [image: 1602429976068-screenshot-2020-10-11-112553.png] I haven't set up the Dynamic DNS through pfSense as it was set up through my home router. ALSO, DON'T FORGET TO SET UP PORT FORWARDING to port 1194 through the home router, otherwise, you won't be able to access the VPN server. I followed this instruction to set up the VM: https://xcp-ng.org/blog/2019/08/20/how-to-install-pfsense-in-a-vm/ I followed this video to set up pfSense on local XCP-ng VM: https://www.youtube.com/watch?v=fsdm5uc_LsU I followed these videos to set up the OpenVPN on pfSense: https://www.youtube.com/watch?v=dBOQnApxzzQ https://www.youtube.com/watch?v=PgielyUFGeQ [0_1602430059510_server1.conf](Uploading 100%)

You were right, an entry on the routing table was off, for some reason, after deleting the ovpn client, user and custom client configs and re-doing them all, it worked fine. Thanks.

Eureka, i founded it. Thanks viragoman, you pushed me in the good direction. Now the vpn icon becomes green and i recieved a ip in the range of 10.0.x.y. on my pc. What was wrong? The "modem" of my ISP is more an AP (with dhcp functionality) then a real modem. It has 1 wan port and 4 lan ports. If you want to connect your own router ehind it, then the ISP router has to be configured with a "passtrough" function . The ip adres from the wan site will be pushed to a lan-port on wich my own pfsense router is connected. So the wan port of pfsense would receive the external isp ip. I my case i saw that my wan ip adres was in the range of the dhcp range of ISP router instead of the external ip. I put the mac adres of my wan port in the configuration .... and it was solved. Thanks a lot Now just i have still to make the test with the iphone and ipad.

@marcor Huh! @marcor said in Site-to-site between pfsense(server) and dd-wrt: LAN_B: Network 192.168.8.0/22 @marcor said in Site-to-site between pfsense(server) and dd-wrt: GATEWAY_B (dd-wrt) $ route Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.8.0 * 255.255.248.0 U 0 0 0 br0 These doesn't match the LAN network mask you stated above. @marcor said in Site-to-site between pfsense(server) and dd-wrt: LAN_B cannot communicate with Gateway_B Really??? @marcor said in Site-to-site between pfsense(server) and dd-wrt: with openVpn client 192.168.129.2/24 Since it is a site-to-site (2 hosts), why setting a /24 mask? Better to use /30 network. @marcor said in Site-to-site between pfsense(server) and dd-wrt: ---- OpenVPN CONFIG ---- On pfsense, I've configured these overrides: SERVER commands: push "route 192.168.32.0 255.255.252.0 192.168.129.1"; route 192.168.8.0 255.255.255.252 192.168.129.2 CLIENT override commands (for LAN_B) push "route 192.168.32.0 255.255.252.0 192.168.129.1";iroute 192.168.8.0 255.255.252.0; Same case, since it is an S2S, there is no need for pushing routes. On pfSense just enter the the remote LAN into the "Remote Networks" box. That's all you need, and don't use Advanced options for that! On the client just use the route option to add the route for the remote network. Additional question: is the DDWRT the default gateway in LAN B?

In my case, the users weren't able to connect to the server through SSH because their traffic was going through the Secondary WAN address. I have 2 WAN ips configured on my pfsense firewall. I used tracert google.com on the client system to check the path. This is how if foundout that the traffic is going through the secondary WAN address. So I added both WAN ips in the SSH access list and the issue got resolved. Now we are able to connect via ssh without any problem.

Hi, Some testing is needed. Like : The WAN interface used by the OpenVPN server is still valid ? Is it listing on that NIC ? The port is ok ? There is a WAN firewall rule ? Put a switch on the WAN side, hook a PC into it, and hit the WAN pfSense IP direct : does it work ? Is the upstream router set up correctly ? New device means often : new WAN IP, so upstream NATting will/can change. Does the OpenVPN server starts ? What do the OpenVPN server logs say ? When you see auth problems, certs etc should be checked. Logs will tell a lot, of course.

IMO it's impossible to tell active directory domain member to not look for dns record of domain name.

Here is some more information which might help. My Router is behind my ISP's Router, so I suppose is 'double NATed'?? If that helps. I have opened The Firewall on the LAN to everything to do with the AirVPN Server address. This is the config the server is using: dev ovpnc1 verb 4 dev-type tun dev-node /dev/tun1 writepid /var/run/openvpn_client1.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto udp4 cipher AES-256-CBC auth SHA512 up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local 192.168.1.153 engine cryptodev tls-client client lport 0 management /var/etc/openvpn/client1.sock unix remote xxx.xxx.xxx.xxx 443 udp4 ca /var/etc/openvpn/client1.ca cert /var/etc/openvpn/client1.cert key /var/etc/openvpn/client1.key tls-crypt /var/etc/openvpn/client1.tls-crypt ncp-ciphers AES-256-GCM:AES-256-CBC comp-lzo no resolv-retry infinite route-noexec fast-io explicit-exit-notify 5 sndbuf 262144 rcvbuf 262144 client persist-key persist-tun remote-cert-tls server prng sha256 64 mlock auth-nocache and here is the info from the ovpn file with the keys in: dev tun remote xxx.xxx.xxx.xxx 443 resolv-retry infinite nobind persist-key persist-tun auth-nocache verb 3 explicit-exit-notify 5 rcvbuf 262144 sndbuf 262144 push-peer-info setenv UV_IPV6 yes remote-cert-tls server cipher AES-256-CBC comp-lzo no proto udp key-direction 1 and the Log Output. The only thing I can spot is this Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key when the Encryption Algorithm is AES-256-CBC (256bit key, 128 bit block) Also the instructions tell you to use Allowed NCP Encryption Algorithms: AES-256-GCM but the above is using AES-256-CBC, I have tried with both, but no good. Oct 4 15:34:09 openvpn 41002 MANAGEMENT: Client disconnected Oct 4 15:34:09 openvpn 41002 MANAGEMENT: CMD 'state 1' Oct 4 15:34:09 openvpn 41002 MANAGEMENT: Client connected from /var/etc/openvpn/client1.sock Oct 4 15:34:04 openvpn 41002 UDPv4 link remote: [AF_INET]xxx.xxx.xxx.xxx:443 Oct 4 15:34:04 openvpn 41002 UDPv4 link local (bound): [AF_INET]192.168.1.153:0 Oct 4 15:34:04 openvpn 41002 Socket Buffers: R=[42080->262144] S=[57344->262144] Oct 4 15:34:04 openvpn 41002 TCP/UDP: Preserving recently used remote address: [AF_INET]185.103.96.130:443 Oct 4 15:34:04 openvpn 41002 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1602,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA512,keysize 256,key-method 2,tls-server' Oct 4 15:34:04 openvpn 41002 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1602,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA512,keysize 256,key-method 2,tls-client' Oct 4 15:34:04 openvpn 41002 Data Channel MTU parms [ L:1622 D:1450 EF:122 EB:406 ET:0 EL:3 ] Oct 4 15:34:04 openvpn 41002 Control Channel MTU parms [ L:1622 D:1156 EF:94 EB:0 ET:0 EL:3 ] Oct 4 15:34:04 openvpn 41002 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication Oct 4 15:34:04 openvpn 41002 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key Oct 4 15:34:04 openvpn 41002 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication Oct 4 15:34:04 openvpn 41002 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key Oct 4 15:34:04 openvpn 41002 Initializing OpenSSL support for engine 'cryptodev' Oct 4 15:34:04 openvpn 41002 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Oct 4 15:34:04 openvpn 41002 mlockall call succeeded Oct 4 15:34:04 openvpn 41002 MANAGEMENT: unix domain socket listening on /var/etc/openvpn/client1.sock Oct 4 15:34:04 openvpn 40744 library versions: OpenSSL 1.0.2u-freebsd 20 Dec 2019, LZO 2.10 Oct 4 15:34:04 openvpn 40744 OpenVPN 2.4.9 armv6-portbld-freebsd11.3 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on May 4 2020 Hopefully this additional infomation might jog a memory somewhere.

That is asymmetrical mess [image: 1601823335277-assmess.png] If you want to use pfsense as downstream routers from your USGs then connect them with transit networks.. [image: 1601823592844-2-transits.png] You could also just solve this with just a transit between your 2 USGs.. 1 pfsense between the 2 of them with leg connected to each USG which would be the transit network connected to each USG. You could also use port forwarding and source natting to solve the problem on every host in your different 20.11 and 20.12 networks. Or host routing so your flow would look like this. [image: 1601824077583-nat-port.png]

Problem solved by unchecking "username as Common Name" [image: 1601821847511-27e7e01e-792b-4ce8-9a5b-f2f2ba671770-image.png]

[image: 1601802028395-fe695c48-00af-41b9-a6be-a71b7e21d13c-image.png] [image: 1601802048586-3dd995af-fb95-4ad1-a2a5-fae44f170ef7-image.png] [image: 1601802080501-c6fbe7f8-5a34-4199-a2b6-6175f1706ce6-image.png] [image: 1601802115421-b19ce9cf-098a-4e1e-97e2-ec91d1d927b8-image.png] [image: 1601802147761-8c13ee03-186b-47c2-89a4-a77a30a5579a-image.png]

You may set there any parameters you want. Mainly you have to enter the client certs common name, a specific tunnel network (/30), the "IPvX Local Network/s" as you already have in the server settings and the "IPvX Remote Network/s", where you have to enter the clients site local networks.

johnpoz...thank you for your replies. Very helpful. Gertjan...it seems after I configured OpenVPN for the second time on pfSense, the 6 minute time is no longer an issue, at least at the time of this post. If anything changes, I'll repost.

@PhlMike said in PFSense as OpenVPN Client: Can I load an .ovpn file or split it up to get it loaded on a pfSense firewall to connect as a client to another service? Hi, Of course, many of us use this to - say, connect to a VPN provider... (with provider .ovpn file) You can't load * .ovpn directly, but you need to configure the client from this file For example, read this description: https://www.expressvpn.com/support/vpn-setup/pfsense-with-expressvpn-openvpn/ The .ovpn file is quite provider specific, so be sure to consult it beforehand... like: [image: 1601663150644-a9b85c4c-711c-4385-9c64-336d2ee85702-image.png]

I don't know the ins and out of how this security device works. But clearly it has a gateway (pfsense). And there is no reason to do the source natting of your vpn connection. From what you have shown the device is answering.. But was showing RST from your client, and Fin,ack from your device to your clients.. Both are ways to END a conversation. So what is actually the issue with vpn vs internet not sure? But from what you have shown pfsense is doing what its told to correctly. I would suggest you sniff on pfsense opt1 interface for your device IP. Set the sniffing packets limit from 100 to 0 so you can see the full conversation... Then start a conversation from internet doing your normal forwarding.. So you can see what is all involved with normal working conversation. Then make sure you kill any states for this conversation.. Reboot the device say, and then doing the same sniffing and talking from your vpn client.. So you can see what might be different? Off the top of head, thing that might be different while your on the actual internet with your client doing port forwarding on pfsense is you have access to internet from your client via the same connection. While your vpn connection would change that sort of connection, etc. Its possible your device phones home and checks something before allowing connection? It could be all kinds of things. But from what you have shown pfsense is doing exactly what it should be doing, and again doesn't care if your coming from the internet or a vpn.. It just allows the traffic or it doesn't..