@WildeRex:

@Koenig:

Started messing around a little with this, but ended up with a nonworking VPN-server, could connect but no access at all to my LAN….

Here is VPN review site. It helped me a lot with my problems :
http://topvpnreviews.net/
:D

Yeah, thank you, but it seems a bit away from my troubles though….

@Nachtfalke:

Probably a firewall or antivirus configuration issue on the destionation host which blocks your ICMPs from other subnets than its own.

Yeah, that just hit me like a brick a while ago  :o

Have to check on it..

Great - just so you know, does not have to be h-node, you could set that to meet your resolution needs.  H is just hybrid will check wins first if one set, then broadcast.

If you don't have any plans for wins, etc then you could just set it to B-node for broadcast only, etc.

Also-

In your open VPN rules put your addresses    192.168.0.0/24 ect…

Your LAN rules have a lot of redundant rules.    The ANY ANY rule pretty much does it...

What version of pfSense are you running?    I havent had a client side openvpn gateway since 2.0.1 came out...

Shouldn't have one on the server side...

Mine-

ifconfig 10.0.8.1 10.0.8.2
lport 1194

Yours (client side)is different from mine…    I don't think yours took...

Through further testing, I discovered that this issue only occurred when doing SMB file copies from a Win7 machine to a Samba server (or vice versa).  The issue was caused by the settings of SO_SNDBUF and SO_RCVBUF socket options in Samba.  The recommended settings of 8192 cause a significant performance hit when transferring files over a VPN.  Changing the settings to 65536 cured the problem completely.

Kevin

Bridged puts you logically on the LAN and could be considered easier, but all broadcast traffic will traverse the tunnel and an ethernet header is added to every packet creating overhead.

Routed functions essentially the same… you can still connect to network shares, ping LAN IP's, ping by name (/w WINS), etc.  Also, only traffic destined to the client or the LAN will traverse the tunnel making it more efficient.  So... to each their own :)

I've never tried a bridged setup, but I'm betting that OPENVPN tab is the OPT1 interface you renamed to OPENVPN and bridged to your LAN per the instructions from http://hardforum.com/showthread.php?t=1663797.

If you add a pass any any rule to the OPENVPN tab you should be able to pass traffic.

Yes I do. All/All Pass.

Its definitely odd behavior… I have rules on OpenVPN, and All/All pass on each OpenVPN interface, assigned and set. And the block would show as coming from that interface. See, TCP SYN packets get through.. its something to do with state keeping. I am not a pf savvy guy (I know the basics, but analyzing the blocks is a bit beyond me at the moment)

Tried that it though I didn't wait that long enough. I ll just tried again if that works. Thanks

Post your tunnel settings and the firewall rules on your openvpn tab.

This line looks like a problem:

Your 10.0.0.9 interface (on your server, if I understood the descriptions correctly) is thinking that it is sitting on a 10.0.0.0/8 network. So when it replies to any 10.n.n.n addresses, it will think it can reach them directly on its local LAN. It should be in the 10.0.0.0/24 network. Then it will send packets for 10.0.10.0/24 network addresses to the router.

Did I put the wrong files??  ???

i dont see a reason to use any kind of nat.

as i understand currently the 10.10.88.0/24 is routed over the vpn and can contact clients on 192.168.78.0/24.

if it were me i'd just add routes on both ends for the openvpn subnet (10.0.34.0/24), that way vpn users can go over the tunnel to reach the devices behind ASA5505.

What were you entering into all of the fields for the CA?

As it says there, one of the strings was too long. Not sure which one it was complaining about though, if we can find out and repeat it, the input validation can be fixed to print a nicer error.

It is now working again  ;D The problem was that one of the routes did not survive the reboot.

I can make one for you also - just send an e-mail to wikiadmin (a) pfsense (d) org and it'll go to anyone who can make it for you. We'll need the username, password, e-mail, and name you want on the account.