No errors. but in system \ certificate no cetificats go back

Won't work out very well. I made setup choices, and have constraints like "a router in front of a router". I'm also using a IPv6 network from he.net, so my OpenVPN exposes also an IPv6 to the connected clients. I decided not to use user and password : the certs on both sides, client and server, will do the authentication. You have to make up your list with what you want, and then you feed Google with "pfsense setup openvpn" and you choose a recent how-to and you follow the step-by-step. Install also the vpn-client-export package. For what it's worth : [image: 1531817259139-fireshot-capture-005-pfsense.brit-h_-https___pfsense.brit-hotel-fumel.net_vpn_openvpn_server.php-resized.png]

Well, looks like i resolved it! It was the logging level of the system. Now it's fast again...sorry for the unneccesary thread.

You should probably paste screen shots of what you have done and not a textual representation of what you think you have done. Screen shots of Diagnostics > Routes, the OpenVPN client and server, and the OpenVPN Firewall rules would be a good start. Please be a little more specific, like instead of I can ping from 10.6.0.0/24 to 10.3.0.0/24 try I can ping from 10.6.0.101 to 10.3.0.62. What is an OpenVPN foreign network ??

I removed all the VPNs and walked through the process again, seems to be working now as it is an available gateway now.

@unknowneleven said in Difficulties on pfSense 2.4.3-p1 and OpenVPN on WAN TCP 443: Hi. I have been trying to make OpenVPN work on TCP 443 since the day one that I installed pfSense. I've managed to get it working in pretty much any port and protocol I've tried, except on TCP 443. I knew that it could conflict with the webConfigurator port, so from the beginning of the installation I changed it's port to 8443, and I've even checked on Sockets that there is indeed no other service binding or trying to bind on WAN:443, only OpenVPN. I've tried to connect on my phone and my notebook, but none will. Ironically, when I try to connect from inside my LAN, it works immediately. It only doesn't connect from outside my network. I've checked my firewall rule on the WAN interface, but it's as it should be. In fact, when I try to connect to the OpenVPN on TCP 443, appears a strange connection on Sockets, with question mark (?) identification on the WAN IP:443 and the other end IP:port. Basically, that tells me that it's not a problem in the end device, for it reaches the firewall. But it seems that pfSense, or OpenVPN, do not identify that connection as OpenVPN on TCP 443. I've tried everything I could find, even the port-share localhost 443. If someone can give me some light, I'll be forever grateful. Thanks. My setup: OpenVPN on WAN, to TCP 443. Firewall rule on WAN: pass TCP any to WAN address on HTTPS (443). Just remembering: OpenVPN works on any other port I tried. It doesn't work only in TCP 443 (though I never tried UDP 443). Also, I've got Dynamic DNS on the configuration, so the client is set to connect to the DDNS.

@aileron said in Route one subnet through VPN, another one through regular gateway?: These will be connected to the same physical interface. Doesn't work that way if your network is 192.168.0/24 you can not just add devices using 192.168.1/24 I would suggest you do some research on basic networking 101 before you start playing with policy routing. Change your lan network to /23 if you want to use both .0.x and .1.x addresses. Or put this .1/24 on its own vlan, etc. Then its very simple to policy route out any clients you want via your vpn. Just make sure to turn off default route from your vpn connection in pfsense and just policy route who you want to use or not use the vpn connection.

@stephenw10 Well you wont believe what it was, it was the WPAD, as site 1 has wpad i also have the proxy auto detect on site 2 i disable the auto detect and bam showing the real WAN ip for the websites. i guess no i have to see how i can disable that.

Is your Unbound service actually running- /status_services.php

The most-specific rules should generally be at the top to prevent something more general from matching first.

@wormuths np problem! good luck with it

Your tunnel networks need to be in the same subnet 172.27.224.0/30 would work for both of them.

I realize that this is an old post, but I couldn't find the answer to the Interface Group order anywhere in the forums. Using /tmp/rules.debug. I found that manually created Interface Groups come before OpenVPN rules. I also found that if you have multiple interface groups then they are processed in alphabetical order. I have three Interface groups: Local for all my local subnets, Clients for local client subnets, and IoT for local IoT subnets. They were processed in the following order: Clients, IoT, Local. When I renamed Local to All_LAN and made a minor change to the rules so they were rewritten, the order changed to All_LAN, Clients, IoT, which is the order I wanted. I realize I probably don't need so many subnets, but using Interface groups and RADIUS to assign VLANs made it easy to setup. I have a VLAN for each person in my household in Clients Interface Group and my IoT devices are in different VLANs by type. It was simple using FreeRADIUS. Thanks

Hello Yes all is working, after some rechearch i found something concerning virus protection. But now my problem is : i have to disable my bitdefender firewall to access to my network. Someone know how to enable the btdefender firewall and add an exception ? Thank a lot

Problem solved. I 'm so sorry to be so stupid i was focus on my local network and forgot the client configuration and change the ip --' I put my public ip and all work fine now. Thank a lot all for your help. Have a great day (i't my bithday today :p = 30yo)

By the way, tap mode changes almost nothing in the scenario. The only difference is that the tunnel network is no longer point-to-point and has broadcast semantics resembling a typical ethernet LAN. Client configuration and routing are still pretty much the same and if you can't get tun mode working properly you won't get tap mode working either.

I would like this feature, too.

Hmm, yes indeed.

Well your authentication retry checkbox would have nothing to do with that.