I feel like a dunce.  I was away from my office and just got back. I looked at the postings and the last one triggered a new thought. I am trying to migrate from ipcop as well as moving from cbeyond. I looked at the ipchicken page and all of a sudden I realized that the default gateway for the internal box was still using the ipcop gateway. Once I changed the gateway from 10.0.1.2 to 10.0.1.3 (the new gateway) everything worked.

I want to thank everyone who posted on this most profusely.  I feel like a huge weight has been lifted off of my shoulders.

I wish I was a little more savvy about all the networking issues, but I guess trial by fire is the way I learn.

Thanks again.

Andy

Simple work-around.  Turn off DNS Forwarding.

Thanks for all the input.

I have got it working now. I did as you suggested cmb and disabled the second NIC in the SBS 2003 box. All seems to be going well now.

Thanks again.

Nick

It should work fine with 1.2b1 without any modification - as you see in your rules.debug output there, you have the NAT passthrough that's automatically generated.

Definitely something out of your control and unrelated to pfsense.

Thank you very much dotdash ! And by the way … PfSense is very nice. Switched from IpCop for it.

I tried snapshot built at 2007-May-18 09:55:34 and the problem persists.

1.2-BETA1 is available on the mirrors, there is an update available. Use firmware page to upgrade after you download the image.

Thanks Dot

SOLVED, thanks.

@hoba:

Not nasty at all

Yeah, NAT is the nasty solution, it breaks all kinds of stuff you would typically want to use across a corporate WAN. Using unique subnets at each remote location is just good network design, it's how virtually every well designed multi-site corporate network works.

ok - my mom used to say (german speaking) "look first - then ask"… i just saw that the cvs already has this fixed...

once again thanks a lot!

Try to decrease the register times to 60seconds. PFsense, along with some expesive-firewalls, have UDP timeouts of 30/60 seconds… after 60 seconds the incomming INVITE will be dropped.

Using STUN doesnt solve the problem. stun is only used to let the phone know the public(masqueraded) address, and how it can open up UDP sessions.

the public IP is needed because SIP (which is osi-layer7) does also contain the IP adress, and some SIP-devices will answer only on that and not on the layer3 ip...(workaround in asterisk is NAT=Yes)

another good idea is to create a NAT rule which does static-port-mapping on the SIP & RTP sessions so that port 5060 stay's always 5060.....

things i haven't checked yet for myself:

SIP over TCP. TCP-sessions have much longer timeouts...but is rarely supported Conservative mode.

good luck

OK, I found my problem.. I have pout any instead of Interface address on the NAT rule :-)

It works now.. Thanks
/MartOn

@marton:

@hoba:

Turn on NAT-Reflection at system>advanced (very bottom of this page).

I tried this, but then all my web requests are beeing redirected to my internal server.

It seems even www.pfsense.com will be redirected to my internal web server.. Any Idea why this happens?

/MartOn

celtic, see:
http://wiki.pfsense.com/wikka.php?wakka=PortForwardTroubleShooting

Now I found the right thread: http://forum.pfsense.org/index.php/topic,1528.0.html - don't know why I didnt find it earliear when i was trying to solve the problem myself :( sorry for the trouble.

Thanks
Arno

I have similar problem. I can't do NAT on WAN2.
On WAN it worked all the time but for WAN wan't  :(
If I set it I allways have WAN IP.
I do VIP's as Proxy ARP, CARP but it never worked.
I try to set WAN2 ip as default route for few machines on LAN. Can somebody knows how to set this?

I'm not using bridge, until now I just named the interface..

The main issue with NAT'ing twice is protocols that are NAT-unfriendly. That includes some VPN client software, some VoIP protocols, FTP, amongst others. These protocols are a pain to deal with when doing NAT once, adding a second NAT into the mix makes it twice as difficult to make these things work right and troubleshoot when things aren't working.

It should be avoided if possible, because it's usually adding a layer of complexity that's unnecessary. In your case, I would see if you could use the modem as strictly a bridge and put the static IP on pfsense.

It doesn't affect packet size because NAT changes the source IP and possibly port (depending on the NAT implementation) on packets, it doesn't add anything to them.

udp reflection should work, the problem seems to be when using a single rule with "tcp/udp". We need to check this.