Are you going to subnet that out downstream or something - yeah I could see quite a few problems with putting 8000 some clients on the same broadcast domain ;)  BTW /18 is what 16382 hosts – quite a bit more than 8000.

And to be honest 192.168.0.0/24 would be a really bad choice for your tunnel network, since 192.168.0.0/24 is a VERY common IP range, so you prob going to conflict with the remote networks local lan space.

Yes, you'd route to the translated subnet

solved
thaaanks.

To solve this problem you can override an entire domain by specifying an authoritative DNS server to be queried for your local domain!

-Services
  -DNS forwarder

the last option…

Services_DNS_forwarder.png
Services_DNS_forwarder.png_thumb

Many thanks for all answer.

Maybe the roadwarrior Pc's firewall causes it. I will test it again. Other good tip to check vncserver binding.

I sidestepped this issue by changing to 1:1 NAT with a separate subnet for VPN clients.

I sidestepped this issue by changing to 1:1 NAT with a separate subnet for VPN clients.

what's the size of those disappearing packets? My first suspicion is they're too large to fit across the VPN.

To add more juice to the issue.

I am current RDPed into a machine from an OpenVPN session. That same machine is running solarwinds TFTP server. I have disabled the firewall on that machine, and I am unable to pull TFTP files from that machine through the OpenVPN Session. This seems odd since I’m able to pull all other services but TFTP..

Please help?

http://doc.pfsense.org/index.php/OpenVPN_Site-to-Site_PKI_%28SSL%29 covers 2.0

@jimp:

Easily solved by assigning each instance as its own interface and then applying NAT rules on the interface specific to the connection you want it to work upon.

Jim,  thanks for the tip.  It's obvious how to do this in the plain-text files,  but not so obvious (to me) how to do it in the PFsense GUI.

What I see now is that you must assign an "Interface" via Interfaces->Assign to each OpenVPN client interface (ovpnc1, ovpnc2) and then assign an Outbound NAT to each one.

Perhaps a Wiki topic for future users?

Thanks again!


Glad its working for you, wasn't really a lot of time to be honest - you can see from the timestamps on the different logins what about 20 minutes or so.

Time well spent on working with a settings I had not played with before, I personally don't have any need for multiple certs or being worried that than cn's don't match ;)

And have not setup password auth either since I have physical control of the device my certs are on – but I can see the desire for these features.  And glad my testing worked somehow got it worked out for you.  I was always sure I could always revoke my cert if lost, but now I have verified that it does work.  In my case though if lost my certs I use - I would prob redo the whole CA portion and gen completely different certs.  But with multiple users revoking clearly a good feature to have working.

I do agree I think the export tool should name the certs based upon the username being exported vs use of the generic naming scheme - I would think a minor rewrite of the export tool?  Maybe you could write up a post download script you run on the zip before handing it off to the user.

And should would be up for a beer or two for sure if ever in the chicago area.

Ok, I figured out the problem. The traceroute tipped me off. Traffic coming from my OpenVPN tunnel to the OPT1 network wasn't being NAT'ed. This is why I wasn't getting a return from the ping. I enabled Advanced Outbound NAT and defined my OpenVPN tunnel as a network to NAT for the OPT1 interface (don't forget to to add rules for WAN too in Advanced Outbound NAT, since Advanced Outbound NAT disabled all the automatic outbound NATing).

Have you read the HOWto's for OpenVPN site-to-site?

http://doc.pfsense.org/index.php/Category:Howto

Otherwise, you could make it easy on yourself and just use Hamachi.

Try this on client:

# The keepalive directive causes ping-like # messages to be sent back and forth over # the link so that each side knows when # the other side has gone down. # Ping every 10 seconds, assume that remote # peer is down if no ping received during # a 120 second time period. keepalive 10 120