Thx a lot. One of the strenghts of pfSense really is that forum, too!

thanks for helping  ;D

hello you can use this tutorial and skip the capive portal if you dont need captive portal!

http://blog.stefcho.eu/?p=754

I forgot you just have 2 nics, maybe you could use a usb nic for the third one?

If you can get an SSH session to a box behind the the pfSense firewall,  Then you can configure a tunnel for 127.0.0.1:xx80 to your pfsense:80 using the standard putty features.

Connection / SSH /Tunnels

Source port xx80  Destination pfSense:80 Add Apply.

Good luck ..

I have one of these, and couldn't be happier:

http://www.lannerinc.com/x86_Network_Appliances/x86_Desktop_Appliances/FW-7535

I got this sub-model: FW-7535F: Pineview D-510 CPU 1.6GHz; w/ 1 x SO-DIMM slot, 1 pair bypass, fanless

Saturating a 20Mbit/s link doing 256bit AES IPSec barely registers on the CPU scale…

I put 4GB RAM in the box, and recently replaced the CF card with a 60GB SSD from intel, which I got for $60 at NewEgg.
The thing is now fast, and doesn't have any moving parts, since it's passively cooled, too.

@stephenw10:

Nice!  :)
pfSense still shows the correct interfaces in the dash etc?

Yep.  :)

Not pretty but if it works…

Indeed…

It should be possible to do this in the webgui IMHO. There was a change to the way bridge interfaces are handled that would seem similar to this problem. Previously the bridge itself could not be assigned as an interface. It seems to me quite likely that if you need to create a lagg to increase bandwidth you might also want to use jumbo frames. Something for the future perhaps.

Steve

Tried to edit in GUI, but it hung on "Save", and wouldn't refresh the page. Probably a browser thing on my end.
I don't see why it wouldn't work to edit /cf/conf/config.xml in the GUI.

Also, this may well work with the preferred <shellcmd>tags rather than <earlyshellcmd>. I tried "Early" first, and it worked, so I quit winners.  :D

I think the "glitch" is systemic with ifconfig(8), and originates in ifconfig not having the capacity to pass a flag for persistence across boots. The FreeBSD ifconfig(8) man never even considers it, but it's common enough knowledge so that we pretty much all know we have to make an entry in rc.conf, either manually or via sysctrl, by the time most of us develop the courage to pop the hood on pfSense.

But pfSense is hardened, and so it can't work like that.
This is the definition of an "ugly" hack in that it has to destroy and recreate something after the fact, but what the hell, it works.

</earlyshellcmd></shellcmd>

@Efonne:

If the remote site that has the public IPs is set up so you route the public IPs instead of directly assigning them to WAN, you could do this with purely routing and no NAT.  The remote site's router would need a static route for the public IPs with the gateway IP being the tunnel endpoint of the local router and the local router could have an interface that directly uses the subnet for those public IPs.  The local router would likely need a firewall rule to force traffic sourced from the public IPs to use the remote site tunnel endpoint as the gateway.  The tunnel endpoints themselves could use private IPs, no public ones there would be necessary.

Okay, I think I understand what you are suggesting. I though the static routes were more for telling traffic where to go, not controlling inbound traffic.

So on the remote router I would do something like this (assuming my tunnel endpoints are 10.100.6.2 (remote) and 10.100.6.1 (local)
Dest Network: Public IP2 (Assuming Public IP1 is reserved for the Wan interface itself)
GW: 10.100.6.1
Then repeat that for IP3 through IP_n.

On the local router I would set up an interface with those same IPs.
A few questions: what kind of interface should I be using for this, VLAN? Something else?
And would I set it up as Public IP1 with a size of /29(assuming that is the network size at the remote site)? If so How does it know that Public IP1 does not need to be routed over the tunnel (since IP1 is the target IP for the tunnel itself)? Can I simply do that with a static route or does it need to not be part of the subnet, and if that is the case do I need to do this with a subnet that is smaller than the subnet at the remote site?

Finally, how would I know that traffic was sourced from those public IPs (to know to redirect it out there)? Would I just need to make sure that it went to specific IPs on my local network (e.g. 10.100.10.200-10.100.10.220 would only be get traffic coming from the remote site so I could create a rule on the LAN to use 10.100.6.2 as the gateway for those IPs.

Thank you very much , i am working on my lab tests now and i will post my results.

push :)

You should ask this in the postfix thread in the packages subforum.

Steve

If I was looking to understand what was going on I would start with:
1. What does "didn't work" really mean? Is too vague a problem description to be useful. A description along the lines of "I did … and I saw ... but I expected to see ..." is much more informative and may even give some hints that help resolve the mystery. Additional information might immediately answer some of the following questions.
2. Is there another system on the network using 1.2.3.122? Perhaps the upstream router? 
3. Does an ftp access to 1.2.3.122 actually arrive on the correct pfSense interface for the port forwarding? A packet capture can help verify this.
4. Does the port forward go to the correct system? A packet capture could help answer the question.

Wally Bob,

Thanks for the help...

To test this I used an on-line ftp tester, ftptest.net, which is really helpful.  I put in my external IPs, it either connected successfully or it didn't.  That's what I mean by "didn't work".

I decided to wipe out my pfSense machine and reinstall from scratch.  So many changes have been made with all the testing and moving it in and out of production, etc., so I thought it might be best to start with a clean install.

I just completed the reinstall.  First thing I tried was ftp coming in to two different IPs.  Not a surprise, it works fine.

Thanks,

Julien

Disabling gateway monitoring is fine for local gateways. There is no benefit to monitoring them.

You really only need to monitor WAN-facing gateways.

Thanks for the reply again :)

Learning to set up VLANs are not a problem for me, it's a skill I was hoping to learn anyways, however I thought my switches supported VLAN tagging, and it seems they do not, so I think a new hardware order is in my future, haha.

Thanks everyone for all your help :D

My BIL gave me the Dell Dimension 2400 I'm using for my pfSense box and 4600 I use for my everyday computer running FreeBSD 9.0. Both were originally running XP but he had taken the HD out of each and had them sitting in his basement.

I had taken the 13.6GB HD out of a Gateway PC and replaced it with an 80GB Seagate around 2000 and used them both for the Dell's. I don't want to jinx myself, but neither have given me any problems over the past 3 months I've been using them since.

because WAN is the only required interface. WAN is the only interface on single interface appliance-type deployments. Nothing prevents you from assigning em1 as WAN and em0 as LAN.