Try latest snapshots it should be fixed.

Hi there! Thx for the reply. I just reinstalled the nmap-package. Running nmap from the console results in the following: [root@betatest.local]/var/tmp(32): nmap /libexec/ld-elf.so.1: Shared object "libpcap.so.3" not found, required by "nmap" root@betatest.local]/var/tmp(33): uname -a FreeBSD betatest.local 8.0-STABLE FreeBSD 8.0-STABLE #0: Sat May  1 18:49:51 EDT 2010     sullrich@FreeBSD_8.0_pfSense_2.0-snaps.pfsense.org:/usr/obj.pfSense/usr/pfSensesrc/src/sys/pfSense_wrap.8.i386  i386 Interestingly, the +CONTENTS file of the nmap-package does not list any dependencies anymore: [root@betatest.local]/(145): grep "pkgdep" /var/db/pkg/nmap-5.00/+CONTENTS | wc -l       0 Regards, dsd

works perfectly fine now

The 1:1 mappings should take care of the address translation for any traffic.  You just need firewall rules to let the traffic through that you want to go through.  Note that the destination used in the firewall rules on WAN will likely be the internal address and not the external address that is mapped to it, because firewall rules apply after translation, not before.

By the way, I've recently added more to the description of the setting on the port forward and firewall rule edit pages to make it a bit more clear.

yeah, welcome to the dark art of OpenVPN's builtin routing table mangler! It took me nearly a week to figure out exactly what it was doing when I did the loadbalancing thing, but once you've got the hang of it, you can get OpenVPN to do the dirty work above and beyond its call of duty of just setting up an encrypted tunnel for you. As a basic crash course, for every tunnel, OVPN creates 2 gateways for each connection. In your case the local end of the tunnel is 10.1.0.6 and the server end of the tunnel is 10.1.0.5 (this is what 'topology net30' does in the PUSH REPLY message). The server then needs to hint to the client what the actual gateway is which also has to be in the 10.1.0.0/16 network (I assume this 10.1.0.1?), so it sets up a second gateway via a static route to 10.1.0.1 through 10.1.0.5. To route to 172.16.0.1 you need to add a third static route to the client so that it knows to send stuff to 172.16.0.0/12 through 10.1.0.1. Thankfully OVPN can do this for you and manage for the lifetime of the tunnel, so add: push "route 172.16.0.1 255.240.0.0 10.1.0.1" to the advanced box in the server page so that the client then pulls this and sets up the route. Force all client generated traffic through the tunnel' box on the server (equivalent to adding 'push "redirect-gateway def1"' to the server conf), and it will setup a further load of routes that overrides the 0.0.0.0 default network and pass all traffic through the tunnel.

http://forum.pfsense.org/index.php/topic,25061.0.html btw, the topic above is not an pfsense-issue. it was a configuration fault. (wrong gateway) from my perspective, i can´t help you further since i don´t know your network. i would suggest you should do a clean installation with a fresh snapshot and a fresh configuration from "scratch", because i didn't had any problems with openvpn's roadwarrior-setup nor read about unsolved issues in 2.0 beta. is it possible that you´re testing in a virtual appliance on the same physical network?

I'm not sure if it would affect anything you're seeing, but there was just a commit for some RRD items this AM, I didn't look at the details though. You might try to update to a new snap (or gitsync, check the doc wiki) and keep trying.

Thank you. Thats what I ended up doing, but I was wondering if there was a way to use a gateway group as default gateway to bypass using firewall rules for that.

Sure! When I configure the squid to use the marks I will post here the configuration file. I'll be waiting for you, guys!  ;D

Hi! I have more than eight queues to graph in each interface. So, the colors are repeated every at the nineth queue. I tried adding more colors to the arrays in the "rrdcolors.inc.php" file in the theme directory, without any results. May be you have a workaroud on this? Thanks in advance.

With yesterday's snap this has got even worse, and this is using the LiveCD version on a VMWare machine… Now, the emX interfaces aren't being configured, and webConfigurator fails to start! :o On boot, I have to use the VMWare console to set the LAN IP address, and restart webConfigurator (option 11), then I have to save each interface individually from the web, and finally save each OVPN client to get the thing to startup. What's worse, is there aren't even any logs as the services (ie logtrap and RRD) aren't even attempting to start! There is something seriously wrong when an OpenVPN client is assigned as an interface, yet in the late March / early April snaps, this was all fine.

There isn't really an easy way to do that from a user-perspective. A developer with access to a 64 bit system will need to build the package or at least add the necessary XML to the package repository to activate it for 64 bit installs.

Can you show me you /tmp/rules.debug.

The pcap shows you're getting fragments, you'll have to allow fragments in your rules.

http://redmine.pfsense.org/issues/586

This is in fact a symphtom of another problem discussed here: http://forum.pfsense.org/index.php/topic,24973.0.html

sorry to hijack this thread but how about if we open a thread, discussing all the rules and traffic shaping stuff and write a doc on it for dummies coz the more options that appear in gui, the more questions arise, such as: y do floating rules have in/out selection and wan and lan and opt1 don't is it necessary to select the interface in floating tab rules as we can multi select it and what if we select and what if we don't where should the shaping rules for download and upload appear, floating tab, lan or wan etc etc it will also help us better understand the internal working of the shaper as well as pfsense itself