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 :)

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.

http://doc.pfsense.org/index.php/Why_can%27t_I_access_forwarded_ports_on_my_WAN_IP_from_my_LAN/OPTx_networks%3F

I know why it didn't work.

The DNS server would be the pfSense box, and the pfSense box is configured to use OpenDNS – which by default nature is through the WAN port, hence why when setting filtering options on StaticIP#1 on OpenDNS' website would "apply" to StaticIP#2 machines as well. DNS queries (and DNS filtering) would be performed through WAN rather than being split and queried from the same interface (OPT1) as the NAT-Outbound assigned static IP.

I think the only two solutions (which one of them really isn't as it does not exist as a feature in pfSense) would be (1) vLAN setup via managed switch (we have an HP ProCurve 4000) or (2) configure pfSense so that DNS queries from the subnet that is set to go through OPT1/StaticIP#2 to also make DNS queries to OpenDNS through the same interface rather than through WAN.

EDIT: I think there needs to be an option under Virtual IPs or better so under NAT->Outbound for entries to manually specify DNS servers that said subnet(s)/IP would use (or if it should make DNS queries through selected interface as well).