Well, site-to-site connections provided by OpenVPN on pfSense certainly qualify for that option.
Plus, the option can be used on pfSense as server, while Windows clients can stay as they are (without this option).

Hi,

I think I found the answers to my questions and probably someone will find it helpful.
On the OpenVPN Server's setup page there is an option to force to check if the user name = certificate's Common Name. If I leave it unchecked the exported client can be used by any user given the user is in AD. I have not tested this scenario but I think it will work.
In our case as we have 5-6 users of VPN I preferred to use the local database. The confusion on how to attach an existing user certificate to a particular user is due to the fact that in order to attach an existing certificate to a user first it is required to create and save the user then edit the user and attach the existing certificate. It is also possible to create a user and generate a corresponding attached certificate by checking that option at the time of creating a user. The problem with this option is you can't edit the details in the certificate (for example the email address) and the details of the CA will be used for the certificate.

I went over some of the bad things with it in your other thread where you mentioned it.  But for another one with tap as you mention you get the same network.  This can be a problem if the remote location your at happens to use the same network which is very common with 192.168.0 and 192.168.1/24 etc.

As to openvpn being blocked, that would have nothing to do with if using tap or tun.

I've ran Wireshark on my system and the "expert" information shows reassembly error protocol tcp

Attached some screenshots

Also, packet capture between the two freepbx shows bad checksum only from remote site to head office.

192.168.185.8.4569 > 192.168.175.21.4569: [bad udp cksum 0xe996 -> 0xb1ab!] UDP, length 14

192.168.175.21.4569 > 192.168.185.8.4569: [udp sum ok] UDP, length 14

Expert.png
Expert.png_thumb

After carefully reading the site-to-site example, I decided that the best thing to do would be to re-vamp my server configuration and see if I can establish a site-to-site connection. I am going to try this at some point today, I'll report back with issues.

Edit 1: I believe I have created a site-to-site VPN between my pfSense router and my Debian VPS; the VPN tunnel will connect, but I am still unable to ping the LAN behind the pfSense router from the Debian VPS. When I reviewed the pfSense logs, I located the following error message:```
ERROR: FreeBSD route add command failed: external program exited with error status: 1

Here is the server configuration: Server listening port and protocol

local 80.1.1.1
port 10000
proto udp
dev tun

Set the OpenVPN subnet

mode server
tls-server
topology subnet

server 10.30.0.0 255.255.255.0
ifconfig 10.30.0.1 10.30.0.2
route 10.0.1.0 255.255.255.0
client-to-client

Misc. IP and security settings

script-security 3
persist-key
persist-tun

Server certificates

ca ca.crt
cert server.crt
key server.key
dh dh1024.pem

Encryption and compression settings

cipher BF-CBC
comp-lzo adaptive

Used for setting static IP addresses on connected clients

client-config-dir /etc/openvpn/static_clients

OpenVPN server logging settings

keepalive 10 120
status openvpn-tunnel-status.log
verb 3

And here is the pfSense client configuration:

dev ovpnc3
verb 1
dev-type tun
dev-node /dev/tun3
writepid /var/run/openvpn_client3.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher BF-CBC
auth SHA1
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 90.1.1.1
tls-client
client
lport 0
management /var/etc/openvpn/client3.sock unix
remote 80.1.1.1 10000
ifconfig 10.30.0.2 10.30.0.1
route 10.0.1.0 255.255.255.0
ca /var/etc/openvpn/client3.ca
cert /var/etc/openvpn/client3.cert
key /var/etc/openvpn/client3.key
comp-lzo adaptive
resolv-retry infinite
topology subnet

Edit 2: I removed the``` route 10.0.1.0 255.255.255.0 ```command from the pfSense client configuration and re-enabled the``` iroute 10.0.1.0 255.255.255.0 ```command on the server in the client-specific overrides section. I reconnected the pfSense router to the Debian server after restarting the OpenVPN service and then connected to the Debian OpenVPN server from another machine. From the other machine, I was able to ping devices on my LAN [10.0.1.X] through the tunnel, but I am still unable to ping the LAN devices from the Debian server itself. Maybe I am missing an iptables rule…? Edit 3: I finally found that the issue has something to do with when the iptables command is passed. I found that if I remove the iptables command``` iptables -t nat -A POSTROUTING  -s 10.30.0.0/24 -o venet0 -j SNAT --to-source 80.1.1.1 ```after the pfSense client is connected and then re-issue the same command, I am able to ping the LAN behind the pfSense router without issue.

Thanks , I found the problem
I change the GW of 192.168.1.20 from 192.168.1.23 to 192.168.1.1 and permit firewall rules allow on WAN from any to 192.168.1.20 (specfic port).
And now I can ping 192.168.1.20 from vpn client.
But , I have another question , why I can not add static route , like "add net 172.16.0.0/26 192.168.1.1" to  achive my gole .
It seems like it is the only way to change the default GW , if the clint build the connection with me , it should be "in firewall subnet" , am I right ? some client's GW with 192.168.1.247 have same situation.

@johnpoz:

"I don't care how it works"

Well how and the F do you expect to troubleshoot it then??  Clearly your seeing two traffic when talking to 135 in your sniffs.  Your seeing a connection and then an answer.

20:45:22.634883 IP 10.1.2.26.50351 > 10.1.1.15.135: tcp 0
20:45:22.635303 IP 10.1.1.15.135 > 10.1.2.26.50351: tcp 0

So your replication issue looks to me like you can not resolve fs01 which is what domain techlink.local

I would suggest you run dcdiag on your DC and validate your dns is all good.  your portquery isn't even going to fs01, etc.

Ok Johnpoz please move on to other threads. I have troubleshot it down to the issue. You are poking down other avenues that are unneeded. BTW, DUH. That prtqry was for the other server on the other side of the vpn.

Anyone else please help. Thanks.

your interface is correct in the OpenVPN config ? No routing issue ?

Good catch, I took it pfsense was the server - but yeah now that I reread it, it could be a server behind pfsense that he is sshing too.  If that is the case then pfsense has nothing to do with it.

Thanks for your help, seems the client didn't like being converted to tap, I recreated a new client config with the exact same data and it worked.

Okay, I see one additional possible reason for this behaviour: the client uses another upstream gateway. So requests come through the vpn to the client, but responses are sent to its default gateway and will be blocked there.
You can resolve this either by checking "Redirect gateway" in the server settings to direct the whole client traffic over the vpn (you can also do this just for this one client with client specific overrides) or you do outbound NAT for the traffic forwarded to this client and translate the source address to the interface IP. The latter has the disadvantage that the client doesn't see the original IP address.

Many thanks for your replies.

I just see this recently posted here:
https://forum.pfsense.org/index.php?topic=118196.0

Will try that and post back if it does not work.

Thanks.
Tom.

EDIT: That worked perfectly for me. I did just need to also disable the default LAN rule.

When you test from your inside host it is connecting out WAN so that is the IP address it will be testing.

You need to create a rule on LAN that policy routes that test traffic out OPT1 so that is the interface the test is done on.

That worked perfectly. Thank you so much.

That makes sense.  I notice, however, that some of the warnings have a source IP that is internal to my network.  How would one explain that?

Ah, shared key.  ok.