John,

thank you, answer was right in front of my face ;-)

My experience with SIP has been bittersweet at times (and I know I'm not alone).
I find things have improved between providers and the current releases of FreePBX/Asterisk/pfSense such that mucking about in pfSense is mostly not needed anymore.
No to mention the SIP protocol itself has evolved (somewhat) for the better, although I still use IAX2 with some setups to avois the NAT nightmare that can SIP can be.

Very often it "just works" which is gratifying after years of trying to resolve  Voip software/ DID provider/Hardware manufacturer issues when everybody pointed at the other guy as the source of the problem <sigh>.

Glad you're up and running.</sigh>

It it nice when the magic finally works  :)

Glad you got i working.

Feel free to ask more if you hit any particular road blocks or have some new config questions.

Understood!!!

THANKS!

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.

multiselect-auth-works.png
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.

Capture.JPG
Capture.JPG_thumb