How have you set up your 'Outgoing Email Server' in the Untangle Email Settings. Are you using Direct or Relaying via another mail server? Both Hotmail and Gmail are very picky about who they receive mail from. If you are sending using the direct option and your Untangle box hostname is not resolvable via public DNS then the mail will be rejected/blocked. If your public IP is dynamic then chances are good that the mail will also be rejected. If in doubt set up the Outgoing Email Server using the relay option via your ISP's SMTP server.

If anyone has any suggestions about this, I'd really appreciate it. Aside from it being a routing issue, I'm out of ideas as to why the server works for ipv4, but not for ipv6. I can post the existing routing on the client and/or server pcs and pfsense if that would help.

because i found this topic already open will update with the same issue i have. The openvpn connection is verry slow. When i try to copy something it gets a max of 50kb/s !!! I have attached the connections for both client(speedtest) and pfsense-openvpn server(console). On the Openvpn side i use: DH Parameter length (bits) - 2048 Encryption Algorithm - AES-256-CBC Auth digest algorithm - sha256 Hardware Crypto - Intel RDRAND engine Should i need to lower those? Thank you  

No what I mean by ACLs is the ACLs in unbound (resolver).. Unless you have turned that off and turned on the forwarder (dnsmasq)?  There seems to be an issue going around with that dnsmasq seeing a conf file and limiting queries to the local network if your using the forwarder. https://doc.pfsense.org/index.php/Unbound_DNS_Resolver#Access_Lists_Tab "I was regurgitating something I read somewhere else on the interwebs." Hehe yeah since we all know everything you read on the internet has to be true ;)  Some of the nonsense I see that says it more secure or better to do something is most of the time complete utter hogwash!! The big thing as of late is dns leakage.. How tight is your tin foil hat??  What dns are you using exactly?  Do you really think your ISP is tracking what IP address 1.2.3.4 (which they know is billy bob their customer) is going queries for..  Oh that billy likes his fetish porn, serve him up more fetish porn ads?  Or maybe they are selling that to ???  The nsa maybe?? While yes data can be gotten from dns queries.. Who do you think is watching yours?  And where exactly are they doing it from?  Once you know who your trying to hide from, then you can figure out how and if you need too.  All comes down to how tight that tin foil hat is…

Right, so the connection still gets opened up. I removed the additional parameter from System -> Advanced. Still works. Of course deleted all "Clients". Still works. No traffic though. I verified that my ovpn-file for this firewall looks exactly like others that work - so I opted to download and install the latest version of the OpenVPN client for Windows. Tadaa. Now everything seem to work as expected. I suspect that part of debugging should be killing the openvpn.exe -process in windows every time, to make sure you don't have stuff interfering. A learning experience.

With the recent upgrades of pfSense, the default network topology changed from net30 to subnet. If your main site changed to subnet after an upgrade and all of the other sites, clients, etc. stayed on net30, you would likely have issues. I would see what the topology is set to on the other networks, i.e. net30, subnet, p2p, then adjust the main site to match and see if that corrects the issue. As a side-note, you can check the OpenVPN logs on the main router by going to Status -> System Logs -> OpenVPN.

Did you install the TAP-Adapter on Windows? The client doesn't find a free TAP-Adapter. Check your network settings.

It's designed to be either completely managed elsewhere, or completely managed on pfSense. In order to revoke a certificate, pfSense needs to have the certificate present. Either in the cert list or on the CRL (it's copied there when you revoke it). The CRL is rebuilt that way because it has to be. It can't add to a CRL it didn't create, since it doesn't have the older certificates on hand to revoke. If you make a new CRL and revoke everything all over again, then you can add to it. But you can't import a CRL and then add to that. That's how it's always worked.

Thanks guys, it was 100% the firewall on the Windows Server. I adjusted the Echo Request settings on the Windows box, and we are in business (Problem 1 Solved). Since this post also included questions / concerns about operating two VPN's at the same time (though the question was mostly answered) I might be asking follow up questions in the next day or two, as we will be testing then. -Specifically, I had to change Local Subnet to Any in this case. .png) .png_thumb)

@Kei: Could someone suggest a working solution for this problem? The correct answer is: Three different machine accounts or certificates. There isn't a good way (or perhaps any way) to accommodate one client with three static addresses in the way you describe. It's far easier and far more secure to configure them one account per device if they must use them simultaneously.

@jimp: If it's for an OpenVPN client, a gateway group should work OK, provided that it's a failover group (only one gateway per tier), though you might have an issue if the group prefers a WAN that isn't your default gateway. Could you elaborate on why this is (and possible workarounds)? I have exactly this set up and I'm running into issues with the client ending up on the default gateway even though it's using a gateway group that prefers a different WAN interface before failover to the default.

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   [image: Expert.png] [image: 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.