The PPTP clients are a part of the main site's subnet so the OpenVPN clients should be able to see them and vice versa. I currently have PPTP clients starting at 192.168.12.101 while the location is using 192.168.12.0/24. The OpenVPN clients have this route already but they cannot communicate. Any more ideas?

yes, I see the 57869 log entries, but what do I do with them.  They have a green box next to them, so does that mean it is getting through?  don't I need to address the side with all the red boxes? It got so bad that  couldn't play my game at all.  I just reset the pfsettings and I'm starting over from scratch once again. If anyone can point me to a very basic link I'd be grateful -=Mark=-

I did as you proposed: Automatic outbound NAT rule generation (IPsec passthrough) Manual Outbound NAT rule generation (Advanced Outbound NAT (AON)) then I deleted the additional rule which was added so I am at the state again as in the screenshot above But outgoing traffic is still on xxx.xxx.xxx.186 and not on the virtual IP. For 1.2.3 there isn't a snapshot available, right? Maybe I should mention that pfsense is running inside a KVM container with PromoxVE. Therefore I did a ngrep on the traffic on all interfaces of the physical hosts (physical IF and bridged IF). But outgoing traffic is always on xxx.xxx.xxx.186 on all interfaces. So pfsense seems not to try to assign the VIP. Incoming traffic on VIPs xxx.xxx.xxx.187-190 works nicely.

I thing I found the problem…. I will be absolutely sure tomorrow that I will speak with my provider. I open an ssh to the router (192.168.1.254) and I tried to ping 192.168.250.5 (pfsense) and I got network unreachable. Then I saw that the static route 192.168.250.0/24->192.168.1.1 is not working ! I thing this is the problem. The router cannot send the packets back to pfsense. Tomorrow I will have news.

@jimp: once they appear in the uverse gateway, you can flip a bit in the uverse router to disable the firewall on those IPs individually. It's just how the uverse router works, and I'm quite certain that's been covered elsewhere on the forum. After the reset I was having some trouble getting the CARP interfaces to show up. Some forum member by name jimp had a bright idea to ping the VIPS and they would should up in the u-vserse gateway. http://forum.pfsense.org/index.php/topic,31167.0.html All looks well so far, as long as I learn then these little struggles are worth it.  ;D

I have a static WAN IP over a PPPoE connection that periodically drops. Upon moving to v2.0RC3 I experienced the problem described in this thread. Solution was to run pfctl -b on the WAN interface IP (or to manually reset all states in the web GUI, or restart the PFSense box which does the same, as already discussed). Basically I want the states between the SIP server and the Asterisk box cleared when the PPP interface comes back up. pfctl -b will clear ALL existing states but it is the only method I have found that reliably works. cat > /usr/local/sbin/voip-wan-wipe #!/bin/sh sleep 30 # Give the WAN routes time to take effect pfctl -b 202.116.181.110 # Clear all existing connection states for my WAN IP Chmod that to 755. Add the following line to the /usr/local/sbin/ppp-linkup file just before the exit line: /usr/local/sbin/voip-wan-wipe & # Run as a separate script to execute in a separate process I can verify this works for my setup. I don't understand why the problem did not present in v1.2.3 for me though. I did also try pfctl -k <asterisk box="">-k <sip peer="">but it didn't work: it said that it cleared some states but it did not result in the SIP registration coming back.</sip></asterisk>

Thank you for your quick reply!!!!

An "other" type VIP does not do ARP. For that you need CARP or Proxy ARP (or an IP alias on 2.0). Also if you are doing CARP/clustering, check the doc wiki for ESX config options you need to set for it to work properly.

Nice to hear that you got it solved

First of all, there is no stupid guestions… I'd do it with carp or other vip, so yes Create after carp vip, assign that new vip to the one machine, which is your server. Make sure that this rule is before automatically created rule Yes it's

One of the biggest headaches I had when setting up pfSense initially was VoIP with my Asterisk server…. it was a pain. I ended up with 3 simple rules however that got rid of the issues, this may or may not apply to your particular situation, but may offer some clue at least :) [image: voiprules.JPG] In this example, the 10.0.1.8/32 address is my Asterisk server. All of my SIP phones and ATA's peer with this server and Asterisk handles the calling to/from outside the local network. Have not had any issues once I figured out this worked for me, YMMV ;) The NAT address is one of my external IP's (I have 5). Hope that helps….

Interesting… I did not realize that was a side effect of 1:1 NAT, so now I know and it makes sense :) I've reverted back to source based routing and port forwarding, seems to be the better solution for what I am trying to accomplish.

Hmeister, Thank you for your assistance, I went ahead and responded at http://forum.pfsense.org/index.php/topic,37661.0.html I will continue to use the other thread only to reduce duplicates.

Check packet captures on the VIP on WAN, if you don't see it there it's an upstream issue (possibly ARP cache upstream that needs cleared). If you do see it there, switch to LAN on the internal IP, see if it's leaving LAN, if it's getting a response.