Hi fgmoyses, Can you send me the details of client and server setup for multiple sites.Because I am tying almost one week to fix this issue.I am very glad if you send me your setup. Thanks and regards.

I see what you're saying. Thanks.

I know it's an older thread but I wanted to throw out two things that helped me.  We have a CARP setup so two routers. router2 couldn't ping the OpenVPN-LAN subnet. Routes looked fine.  Solution: reboot router2. When testing, router1 worked fine. Router2 connected and I could ping the router but not further. Solution: devices on the LAN are set to the CARP alias IP as their gateway, so the VPN through router2 will only work if CARP failover is in effect so that IP is shifted to router2.

You just need to create an outbound NAT rule which translates source IP of packets leaving pfSense on your "problem interface" to the interface address. This solution works, no matter if DHCP is on or not.

Hrm. After increasing the logging level to 4 again from the recommended 3 I'm now seeing this message a lot: MULTI: bad source address from client Gotta get to bed for tonight but it seems like the IP that is showing up at the OpenVPN server is that of my local wifi connection and not the VPN IP that should be showing up. ~Brett OpenVPN config: <openvpn><openvpn-server><vpnid>1</vpnid> <mode>server_tls</mode> <protocol>UDP</protocol> <dev_mode>tun</dev_mode> <ipaddr><interface>wan</interface> <local_port>7696</local_port> <custom_options><caref>snip</caref> <crlref><certref>snip</certref> <dh_length>1024</dh_length> <cert_depth>1</cert_depth> <crypto>AES-128-CBC</crypto> <digest>SHA1</digest> <engine>none</engine> <tunnel_network>172.16.snip/24</tunnel_network> <tunnel_networkv6><remote_network><remote_networkv6><gwredir>yes</gwredir> <local_network>192.168.snip/24</local_network> <local_networkv6><maxclients>10</maxclients> <compression>adaptive</compression> <passtos><client2client><dynamic_ip>yes</dynamic_ip> <pool_enable>yes</pool_enable> <topology_subnet><serverbridge_dhcp><serverbridge_interface>none</serverbridge_interface> <serverbridge_dhcp_start><serverbridge_dhcp_end><dns_domain>snip</dns_domain> <dns_server1>192.168.snip</dns_server1> <dns_server2>8.8.8.8</dns_server2> <dns_server3>8.8.4.4</dns_server3> <dns_server4><push_register_dns>yes</push_register_dns> <netbios_enable><netbios_ntype>0</netbios_ntype> <netbios_scope><no_tun_ipv6><verbosity_level>4</verbosity_level></no_tun_ipv6></netbios_scope></netbios_enable></dns_server4></serverbridge_dhcp_end></serverbridge_dhcp_start></serverbridge_dhcp></topology_subnet></client2client></passtos></local_networkv6></remote_networkv6></remote_network></tunnel_networkv6></crlref></custom_options></ipaddr></openvpn-server></openvpn>

Generally, on interface rules that are evaluated top down - first match wins, if you want to limit what the users can do you go from most specific to least specific: Pass what your users need to access - DNS to DNS servers, pings to gateway for troubleshooting/comfort, etc. Block what you do not want your users to access - DMZ to LAN or other local networks, webConfig (don't forget WAN address or This firewall (self)), etc. Pass everything else - (the internet)

@Derelict: Just look at the OpenVPN threads.  There's a really long one about PIA that covers all this.  Sorry, I don't have a bookmark for it. There's a checkbox in the OpenVPN client config that says don't pull routes.  With that checked make an alias for the hosts you want to go out the VPN and set the VPN as a gateway in a matching rule. Appreciate the help. Will look for the post on PIA so I can figure it out.

Meaning all clients get routes to 10.0.0.0 and 10.0.1.0.  The firewall rules control who can actually talk to what. It just lets you standardize the server config for all users.  You can also just push specific routes to local assets to specific users.  OpenVPN will pretty much be able to do anything you can think of.

;) "Science bitch!" - Breaking Bad. I would say that it works. I authenticated with two account found in the separate backends  :o. [image: multiselect-auth-works.png] [image: multiselect-auth-works.png_thumb]

I deleted the Server and disabled the working Client for now.  I have pasted the logs to a pic attached. [image: Capture.JPG] [image: Capture.JPG_thumb]

On further investigation, it seems that pfsense is doing exactly as it should, it is assigning itself the 42.1 address, it's the dd-wrt router that is insisting on the .5 and .6 addresses. Thank you for the links though, definitely good information that I didn't know before

Yes, you're right. You have to select "Network" at destination type and enter your alias in the field below.  

Thank you for your response! Sometimes a solution is really simple but you just forget to think about it. Great that a forum like this has other users who are experienced and who can give you the right tips. You made my day, it all works flawlessly! ;D Kind regards, Dennis