@Phobia: Something has again broken the functionality here as well as a press of disconnect now results in a loss of IP address, but the interface still shows as online with an IP of "0.0.0.0".  As the interface still thinks it is online, there is no "connect" button, and the only way to restore the connection seems to be a reboot. The same situation with DHCP. But reboot not help. After reboot  IP 0.0.0.0

The wizard code needs to be updated. It still saves an IP address in the <interfaces><$if> <gateway>tag. GB</gateway></interfaces>

After the recent gateway code updates, you need to edit and save each gateway entry. In some cases with automatic/dynamic gateways you be better off deleting them and letting the system recreate them.

ok. So that Euro is a real funny thing… Its like an easter-egg. :)

thanks much for that info!

Selecting the wrong type is where you went wrong. Ports fields only complete port type aliases. The input validation may need some work, it's always fuzzy with aliases since there are many things that are valid depending on the type (IPs, ports, hostnames, other aliases, port ranges, URLs, etc)

There isn't a way to enforce the IP assignment with the IPsec client in that way, unfortunately. You can set per-user IPs given from the server side with OpenVPN, and also with PPTP. Those can't be changed by the user.

yep. But seems to be gone. Since today no more entries like this. (fresh updated)

That appeared to work! Thanks a lot!

There seems to be a widely held view that at least the early Realtek NICs were pretty terrible. Perhaps you have some of that vintage. I have a couple of Realtek 10/100 PCI NICs and they seem to work OK for me. A while ago even dual port 10/100 Intel NICs were available quite cheaply on Ebay. I don't know the current situation. I forget the details now but a fairly recent FreeBSD driver for Intel 10/100 NICs had a bug in that it erroneously determined that some Intel 10/100 NICs had capabilities they really didn't have. I suspect some of the older NICs might not get a lot of test cycles from the FreeBSD developers. You might be better off spending a bit more money and getting a more current NIC.

you have to have vlans at both sites: for example: Site A: vlan 100 - data = 192.168.100.0/24 using ipsec tunnel A vlan 101 - voice = 192.168.101.0/24 using ipsec tunnel B Site B vlan 102 - data = 192.168.102.0/24 using ipsec tunnel A vlan 103 - voice = 192.168.103.0/24 using ipsec tunnel B that's how i would approach it but as i say, i've not tried this. i'm not sure if the vlan headers would work via an ipsec.

thanks, ill give it a try

Edit the following line in /usr/local/captiveportal/index.php $ourhostname = „{$ifip}:8000“; ändern in $ourhostname = „<ip pfsense="">:8000“;</ip> This work around doesn't work… captive portal + transparent proxy 2.0-BETA4 (i386) built on Sun Sep 26 20:34:55 EDT 2010 FreeBSD 8.1-RELEASE-p1 add bold text in``` /usr/local/captiveportal/index.php header("Expires: 0"); header("Cache-Control: no-store, no-cache, must-revalidate"); header("Cache-Control: post-check=0, pre-check=0", false); header("Pragma: no-cache"); **header("Connection: close");**

For anyone who finds this thread later: It turned out to be browser behavior.  Try a different Web browser if you have this problem.

Thanks for your reply, I running on Ver 2 beta 4 snapshot Sep 9. I have no choice switch to use openVPN because my situation is one site was setup VPN over IPSec by Cisco ASA 5500 and they only allow us connect to them on 2 IP, therefore i must find the way to NAT that IP for connect to VPN from inside local network with difference subnet.