I was able to connect to my PCs' internet addresses from begin the firewall once I went into Advanced > Firewall/NAT and checked the box labeled: Automatically create oubound NAT rules which assist inbound NAT rules that direct traffic back out to the same subnet it originated from.

In other words, when connected to a PC on my LAN, with that box checked, I can now connect to machines using their internet addresses instead of being forced to use internal, LAN IPs.

@repa:

currently only one to test it.

Firewall is LAN -> WAN "Default allow LAN to any rule "

Outbound NAT is "Manual Outbound NAT rule generation" with no entry.

When using manual outbound, you need to specify outbound nat.

Change it to manual to test and then Back to manual.

Perfect… Thank you so much for the sparring. :)

Hey,
  with 2.0.1 the NAT is not a problem anymore. If you still have the problem, maybe could be a "traffic shaping" queue. I mean, the CARP traffic can be dropped under heavy traffic, and this can bring to an inconsistent CARP status between the master and the slave box.

I am not sure, I figure out that could be a traffic shaping problem today… this is my post:
http://forum.pfsense.org/index.php/topic,45045.0.html

Ciao,
Michele

Hello,
anyone that can pls confirm this? Now it's 3 days, 6h that the two firewalls are working and everything is going great!

The problem was:
WAN Interface: x.x.x.x/24
2 CARP VIPs (on 83) were: x.x.x.x/32

The question is: Can this misconfiguration bring to an inconsistent CARP status (half of VIPs Master on one firewall, the other half Master on the other firewall)?

Thanks a lot,
Michele

All kernels (even Dev) are SMP on 2.0.

There is no longer any benefit to loading a uniprocessor kernel (Mentioned a little here but also in more detail by me around the forum).

I've had some issues with the dev kernel in certain setups as well but it does a lot more strict locking checking and reporting, which is what you appear to have hit here.

We have enough debug info in the stock kernel these days that the full dev kernel isn't quite as necessary on its own, but still useful in rare cases.

Thanks I will discuss it with him. Thanks so much for the help!

Chris

@dmitche:

Untangle drops all VLAN tags when it rebuilds the packet so I cannot pass and tags to/through it :(

create three new vlans, apply it on pfsense and untagle port

then you can setup this:

workstation –--- vlan19 ------ untagle bridge ----- vlan119 pfsense
workstation ----- vlan20 ------ untagle bridge ----- vlan120 pfsense
workstation ----- vlan30 ------ untagle bridge ----- vlan130 pfsense

assign 10.10.30.1/24 on vlan 130 at pfsense
assign 10.10.20.1/24 on vlan 120 at pfsense
assign 10.10.19.1/24 on vlan 119 at pfsense

The last IPsec config, if deleted, would not be removed from the secondary in 2.0. That's fixed in 2.0.1.

CARP and multi-WAN are two separate, unrelated things. Though you could hack apinger's config to run a custom script that disables CARP when a WAN goes down and triggers a filter reload, and another one that re-enables it + a filter reload when a WAN comes back up.

you may need to split your questions, I can't see carp issues, just pptp issues

To change xml, backup your config first, got to console, remove duplicated entries from /conf/config.xml and reboot.

could be done but not supported officially

http://forum.pfsense.org/index.php/topic,40917.0.html

cmb,

I went back to the book, and learned quite a bit. I was misunderstanding the options in the rules setup, thank you for giving me a direction to look in, I have it working now.

In the end I had a look through the firewall logs and saw the 'easy setup' option to create an allow rule and followed the syntax. I didn't realize the feature was there, I'll remember next time.

Answering only the first, do you have set these kind of rules to your vlan's?
from vlan-subnet (or any) to any

If yes then problem is your rule sets. you can create such alias called localnetworks and add all local networks to that alias.
Then add this rule to your vlans

block from vlan subnet (or any) to "local networks" and make sure that this rule is above any other rule.

Has to be static and all on the same subnet so that won't work for stateful failover. You can do CARP only on your internal interface, and just lose all your states when you fail over. That's what I do on one of my WANs at home where I can't get static IPs, have two DHCP IPs and just live with losing states when it fails over.

More info.

I have another NAT mapping, identical to the 443, but this is for port 25.  It works perfectly.

So I tried to change the NAT like so:

WAN2    TCP    *    *    IP3    444 (HTTPS)    PDC    443 (HTTPS)

And that works perfectly.  Accessing it on http://IP3:444/ works always.

Changing it to:

WAN2    TCP    *    *    IP3    443 (HTTPS)    OTHER_SERVER    443 (HTTPS)

Causes the same issues - hence it is not the destination server at fault.

The other mapping I have is also identical to the 443, but for port 80.  This one works too.

As I said, loading the NAT on IP1 (the WAN2 real IP) works to 443.

State table entry after a telnet that connected/disconnected looks like this:

tcp PDC:443 <- IP3:443 <- 96.55.212.111:64668 ESTABLISHED:ESTABLISHED
tcp 96.55.212.111:64668 -> PDC:443 ESTABLISHED:ESTABLISHED

Any help would be appreciated.