If the test uses a fixed TCP window size, then the bandwidth achieved will be limited by the combination of window size and round-trip delay. e.g. the window size above is 64.2KByte. That means that the test will send 64.2KByte of data, then stop sending until it gets an ACK from the 1st packet…. - never having more than 64.2KByte of unacknowledged data. For example, if your round-trip delay (latency) is 100ms (0.1sec) then the maximum throughput on TCP is:

64.2KByte10248bits / 0.1 sec = 5,259,260 bits/sec

Try using a bigger window size, that might help the test if the latency from client is high.
Of course, your Alix 2D13 might be max'd out anyway.

@jader:

Any news about pfSense2 authenticate against SME8 LDAP ?

I'd like to have it running SquidProxy/DansGuard authenticated!

Hi,

I am interested in too… (pfSense v2.0.1)

But can't get it working so far...
But keep trying...

Regards,

Hey guys, just so you know, I recently went through troubleshooting why my VPN connection was so slow (3Mbps on a 25Mbps link). I tried some of the recommendations in this thread and others, but nothing helped.

Turns out I set the transport to TCP (bad) when I created the server. I switched to UDP and now I get fast speeds (nearly 25Mbps).

Apparently so. I guess I can chalk this one up as a good learning experience.

Solution: Switch OpenVPN to UDP!

FYI- We have some of that procedure documented here:
http://doc.pfsense.org/index.php/Using_EasyRSA_Certificates_in_2.x

the static routes are in place in pfSense, for example:

10.1.2.0/24 via 10.1.1.1 (L3 switch interface)
10.1.3.0/24 via 10.1.1.1

And I agree that my OpenVPN client might need to know those, assuming they aren't included in the config file I generated with the export utility.

What I don't understand is why it was working briefly… and why I can't hit anything on the 10.1.1.0/24 network, which is where the pfSense inside interface is (10.1.1.254) and which should be routed automatically.

That makes sense, I'll try that.

you are my hero hahaha
i thought that proxy authentication is the place where i put my user+pass

IT WORKS :D

thank you

heper,
I tried setting up ospf as you described but for some reason the Quagga UI makes some changes that I didnt specify while ignoring other that I do.

I have two openvpn tunnels. The tunnel networks are conn1: 10.1.1.12/30 and conn2:  10.1.1.16/30.
The quagga will sometimes add those two networks as networks to distribute without me specifying them. So if conn1 is up while conn2 is down ospf will add a route to 10.1.1.18 via con1 and it will prevent the openvpn connection conn2 from coming online (openvpn client fails to add the route).

Another issue i was having was being able to distribute the openvpn 'Remote Users' network via quagga. I have a 'Remote Users' openvpn server with network 10.2.2.0/24.
I tried to add the network to be distributed via ospf but it only distributes the route 10.2.2.2/32

Oddly enough both these issues dont' appear when i use openospfd.

Any help would be greatly appreciated.
-E

Okay, I have this working now.

I put the```
push "iroute 10.0.0.0 255.255.255.0"

Ini order to register the phone I had to manually provision the phone. It will not auto-provision, I assume because pfsense doesn't pass the option 66 for TFTP to the Virtual Lan clients? Either that or OpenVPN doesn't support passing said option? Thanks for the help thermo!

Thank for you reply.

This is my server config:

dev ovpns1
dev-type tun
dev-node /dev/tun1
writepid /var/run/openvpn_server1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-128-CBC
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local x.x.x.x
tls-server
server 10.1.1.0 255.255.255.0
client-config-dir /var/etc/openvpn-csc
tls-verify /var/etc/openvpn/server1.tls-verify.php
lport 1194
management /var/etc/openvpn/server1.sock unix
push "route 192.168.2.0 255.255.255.0"
ca /var/etc/openvpn/server1.ca
cert /var/etc/openvpn/server1.cert
key /var/etc/openvpn/server1.key
dh /etc/dh-parameters.1024
tls-auth /var/etc/openvpn/server1.tls-auth 0
comp-lzo
route 192.168.88.0 255.255.255.0 10.1.1.2

Looks like it was just fixed– old archive on the package server, a simple uninstall and reinstall as of a few minutes ago fixes it.

So on the HO firewall I've activated AON and created a manual rule to NAT my remote subnet as stated in different post but it's still a no go. (see attached jpeg)
I can reach internal web server from Remote site but still no Internet.
Running on the last pfsense distro 2.0.1-RELEASE (i386)

Anyone for any help please?

AON_HO.jpg
AON_HO.jpg_thumb

Remove the package, run a firmware update.

tap isn't really properly fixed until 2.1, the patch was just a half-hearted attempt to get it working on 2.0.x, but it doesn't fix everything for everyone.

If you really want tap, use 2.1-BETA

In that case say your fqdn is server.something.tld  place something.tld in "DNS-Domainname," pfsense LAN IP in "DNS-Server" and make sure you can resolve fqdn through pfsense (place it in Services > DNS Resolver) and you should be able to open up \server as well.

Disable nmb service, remove WINS from OpenVPN and don't forget to reconnect.

That shows you can't connect to the server's IP on TCP 1194. It's generally preferable to use UDP for performance reasons, but that aside, the most common causes of that:

no firewall rule allowing TCP 1194 to the server IP on the server side. network the client is behind doesn't allow TCP 1194 outbound wrong server IP or port