I had tried creating NAT –> Port Forward: Interface: LAN Protocol: TCP Destination: Single Host & <ip of="" my="" a="" server="" which="" require="" passing="" by="" proxy="">Destination Port: HTTP Redirect target IP: <ip of="" my="" other="" proxy="" server="" in="" another="" subnet="">Redirect target Port: 8080 NAT reflection: use system default Anything that I miss?  >:(</ip></ip>

Yes, you can connect directly to the Nortel, and it sounds like your Cisco isn't doing anything for you so you may as well remove it.

pfSense rules apply to traffic arriving on an interface. For the simplest start, create rules on the LAN and DMZ allowing access everywhere (see the Default rule for the LAN interface in your second post). If at that point you still have problems communicating between the LAN and the DMZ it is probably because of the computer's you're using. Start by giving each their own /24 (say put the DMZ on 172.30.11.0/24 and give the LAN 192.168.0.0/24).

I have tomato working with MLPPP perfectly fine. I turned off DHCP and to test that the internet and MLPPP is working i used a static IP assigned manually in windows. As well, it is running on 10.1.1.1, and I will be assigning 10.1.1.2 to PFsense, with the hope that 10.1.1.100 - 10.1.1.150 would be DHCP from pfsense. I just havent figured out how to get tomato hooked into PFsense, I have it assigning IP's already through a second router running dd-wrt that is wired to the box I want to use for pfsense. DHCP on that is off as well, and I can connect to pfsense web admin and see myself there in the list of clients no problem.

Unbelievable but it was hardware issue.

Just add a static route, for 192.168.20.0/24 with a gateway of 192.168.2.254,

I've been trying to dig into this a little, and workarounds to make OpenBGPD and OpenOSPFD usable.  It looks like the core issues is FreeBSD only allows a single entry in the routing table to any given destination; when the interface is brought up you have a route to that network out that interface, but when a routing daemon learns that same prefix and updates the routing table, it overwrites the first entry.  FreeBSD supports multiple FIBs now, but it looks like pfsense is built with only one, so I'm trying to find solutions within that constraint. It turns out fixing OpenBGPD is easy - you simply add a "Metrix X" parameter to each of your defined neighbors with a value greater than 1. I'm still working on OpenOSPFD (and ospf/bgp together).  There's a "Metric" under the interface settings tab, but that's something different (it's the ospf interface cost).  I'll keep this updated with what I figure out.

I suggest you do a packet capture on every other interface to find where the traffic is leaving from the PPTP subnet.

The specifics are covered in the doc wiki and elsewhere on the forum. It's a common task. You just need to setup the Virtual IPs, 1:1 NAT, and firewall rules to let traffic in. It's been asked and answered many times on the forum before.

Thanks for your help.  :)  I'l try your suggestions… ...and wait patiently for the day when 2.0 is final and I can bind additional addresses to the actual interfaces and eliminate the need for some of these workarounds.

The problem is that they are aquired via DHCP and i do not know what the IP-address will be until i get hold of it. And there does not seem to be a DHCP-option i the VirtualIP setup.

thanks for all. i did it using schedule and lan firewall rule. first i greated new gateway group for wan1 and wan2 with tier 1 and gateway group for wan1, wan2 and wan3 with tier 1 then i created schedule every day from 8 am. to 11 pm., and from 11 pm to 8 am then i created two lan firewall rule: first rule for load balance wan 1 and wan2 with schedule every day from 8 am. to 11 pm second rule for load balance wan 1, wan2 and wan3 with schedule every day from 11 Pm. to 8 am. thanks for all

Update Also attached is a screen shot of PFtop showing what happens when I plug in WAN1 or WAN2 Nic cards on my Test Pfsense. Can you deduce anything from it? [image: Pftop.png] [image: Pftop.png_thumb]

The best temporary solution is to make a failover group and assign traffic that needs a static connection to the failover group instead of the round-robbin.