Hi pfbits,

I found out myself after you pointed me in the right direction.

I had a faulty DNS suffinx setting on the VPN adapter. This was due to misconfiguration of OpenVPN (I changed my domain name at one time).

So now everything is working as it should.

Thank you very much for helping me out.

More detail:
I connected to ovpn.
I then connected to a vmware vsphere application to use the console of one of the VM's in the office.
I compared pinging from the VM to pinging from my home laptop.

Format:
Internal IP / ping from home Y/N / ping from VM Y/N / description

ex:
1 Y/Y - office pfsense means the IP of the machine is 192.168.1.1  (note the "1"), and the Y/Y means I could ping it from both the internal VM and my home laptop.

To me, the anomalies are the .10 server attached to the same "server switch" that seems to provide the most reliable results.  I assume this is a client firewall issue on the .10 machine itself.

Also the difference between the .60 and .68 - why would one machine on a random switch respond to ping, but the other would not?  Again, do I assume a client firewall issue?

Finally, the .22 machine is the internal test machine we've been working with.  Firewall on or off, no difference.  Static route on the machine or not, no difference.

It still seems that most of the machines on the "server switch" want to act right, while most of the machines on other 8port workgroup switches in the office want to not work at all.  I would chalk it up to "firewall" on all machines if it wasn't for the fact that I know we have 100% disabled the Windows firewall on the .22 Ip with the same (failed) results.

EDIT: I should note, notice that from an internal machine on the LAN, all pings to target machines worked as expected. (The "Y/Y? column has all Y in the 2nd part)
EDIT2: for IP's 57-84 I cannot comment on the OS or state of the firewall at this point - I assume some are on, some are off.  I also assume that most (if not all) are Windows 7 workstations.

1 Y/Y - office pfsense
5 Y/Y - office 24port switch directly attached to pfsense
7 Y/Y - wifi access point daisy-chained to an 8port workgroup switch
9 N/Y - wifi access point daisy-chained to an 8port workgroup switch
10 N/Y - physical server (windows) attached to 8port "server switch"
11 Y/Y - physical server (linux) attached to 8port "server switch"
12 Y/Y - physical server (windows) attached to 8port "server switch"
13 Y/Y - physical server (imac running OSX) attached to 8port "server switch"
14 Y/Y - physical server (vmware esxi) attached to 8port "server switch"
15 Y/Y - 2nd physical server (vmware esxi) attached to 8port "server switch"
16 Y/Y - vm guest OS (linux) on vm1 (ip .14)
17 Y/Y - vm guest OS (linux) on vm1 (ip .14)
20 Y/Y - physical NAS server (synology) attached to 8port "server switch"
21 Y/Y - vm guest OS (windows 7) on vm2 (ip .15)
22 N/Y - physical workstation (windows) - my primary internal test machine
30 Y/Y - vm guest os (linux) on vm1 (ip .14)
33 N/Y - vm guest os (linux) on vm1 (ip .14)
35 Y/Y - vm guest os - linux - 2nd NIC of physical vm server - this is the mirror port of the 24 port switch attached to pfsense
37 Y/Y - vm guest os (linux) on vm1 (ip .14)
57 Y/Y - physical workstation attached to some misc 8port workgroup switch, attached to the 24 port switch that is attached directly to pfsense
60 Y/Y - physical workstation attached to some misc 8port workgroup switch, attached to the 24 port switch that is attached directly to pfsense
68 N/Y - physical workstation attached to some misc 8port workgroup switch, attached to the 24 port switch that is attached directly to pfsense
70 N/Y - physical workstation attached to some misc 8port workgroup switch, attached to the 24 port switch that is attached directly to pfsense
79 N/Y - physical workstation attached to some misc 8port workgroup switch, attached to the 24 port switch that is attached directly to pfsense
84 Y/Y - physical workstation attached to some misc 8port workgroup switch, attached to the 24 port switch that is attached directly to pfsense

Hi did you ever get this working?

I am trying myself to get this working (open vpn and IP Alias) but no luck so far.

How many nodes does your home network consist of? normally for home users its one computer and router and maybe a few ipads for the kids. Just change the network range on the router. So much easier!

I figured it out! The missing piece was that I had to create a new interface (which I called "BRG") and added the bridge adapter to it. From there, I was able to assign it an IP address (which wasn't necessary except for ping testing), and, most importantly, add firewall rules to that interface. From there, it was a simple matter of adding an allow any to any rule on that interface, and now I can ping over the bridged VPN.

Hi,

Has anybody any other recommendations for a vpn provider?

Thanks

Richard

I had the exacy same problem for quite some time, and it's still not quite clear to me why it doesn't work, but this is what I found:

The port forwarding itself work just fine, the problem is when you combine this with policy routing in such a way that you need a policy route to "activate" to route the traffic out through the correct interface. Since the incoming, port-forwarded packets are placed in the state table, and thus when the computer on the inside replies to that packet, the reply is automatically accepted via the state table. Because of this, the policy routing rule is never evaluated, and thus the packet defaults to the default routing table - usually ending up exiting through your WAN, not the VPN tunnel. Since these addresses are normally in a private range, the packet will just die alone in the cold in some router out there on the internet.

In pfSense 2.1 they have made some fix to this that auto creates a "reply-to" rule when you create an incoming NAT/port forwarding. This works, and you can find it in rules.debug, but for some reason it doesn't seem to be executed correctly in all cases (not in my case atleast). What I did to correct the issue, was to make a floating rule, placed on top or near the top of the floating rules, that basicly exactly matches the auto-created interface firewall rule that the NAT/Port Forwarding rule generates. The only visible difference for me, is that this rule ends up much higher up in the rules.debug ruleset, but it makes all the difference - and suddently the portforwarding from a openVPN tunnel works perfectly.

One change I did:  When the upgrade came to 2.1 I checked the previously unchecked box asking that the master and backup synced via pfsync for OpenVPN.  So either something about the upgrade broke site-site or checking that box broke site-site.

As a test, I unchecked the box and disabled the client and the server setup on the backup pf box, leaving them run on the master pf box on both the client and server ends of the site-site.  And… after a reboot... it works now.

Site-Site OpenVPN does not like the openvpn HA pfsync box checked.  I suggest to check it during the configuration of the master, then before enabling the setup, save it disabled, so the backup PF box gets the config.  Then uncheck pfsyncing the OpenVPN, then enable the config on the master.  The good news is that it will work.  The bad news is that should the master go down you'll have to manually get up at 3 am to enable the config on the slave.  I think it is a rule that PFsense boxes only fail at 2:45 am.

No, I also cannot connect locally, though the openvpn services shows as running. Also tried to reboot PFSense, but no change.

@jimp:

If you connect and then are disconnected a minute later, the most likely cause is having two clients connected with the same username/cert at the same time.

When one connects, it will work for a minute, and then the other one will reconnect after 60 seconds and bump the first one off, and then it will work for 60 seconds until the first one reconnects and bumps it off, repeat, repeat, repeat…

Hi,

thx for the reposnse.
I have try with windows, mac, linux, iphone, android, etc…. and the connection is very instable... In the GUI I view only one connection and I'm sure that the client try to conenct once. About 10 - 15 days ago the OpenVPN works perfectly...

Not enough information to tell there. You'd need to see the logs from the server side to say for sure.

The traffic may not make it all the way to the server, or there could be a mismatch elsewhere in the settings that prevents it from linking up.

The credentials for the VPN are not related to the credentials for mapping drives, they have no shared knowledge.

Windows has a long history of refusing to save share passwords as expected. Some versions you have to go into the user account settings and manually add an entry for the server and password. Others you can get away with accessing \x.x.x.x directly and then checking "save password", either way, that's all up to the client OS, not the VPN.

Sounds like the RADIUS server to me. Perhaps there is something in NPS on server 2008 that is causing the logins to be rejected.

It sounds like it should be logging more than what you're seeing.
http://technet.microsoft.com/en-us/library/cc753898%28v=ws.10%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/bb892007%28v=vs.85%29.aspx

the idea is to browse the vpn

I was watching the other examples like StrongVPN and TUVPN

that there is nothing vpnbook?

or I can help you pull and q aprobechar vpnbook is free

Sonicwall is using 10.0.0.0/8 for its LAN network. That conflicts with the tunnel network that you have chosen. So the server pfSense will be confused about where 10.0.8.0/30 actually is.
Either:

I can't believe that your main office needs 10.0.0.0/8 for a LAN. If it just uses address like 10.1.1.* then make it 10.1.1.0/24 or even 10.1.0.0/16 - but that might be rather difficult for you to implement. Choose a tunnel network in different private IP space - for some reason you have already used the whole of 192.168.0.0/16 as the client end LAN? 172.16 is still possible, makeup a tunnel subnet like 172.16.42.0/30

At main office, Sonicwall will need a route to 192.168.0.0/16 through pfSense LAN IP 10.1.1.253 - this will allow systems on main office LAN to send packets to your client end using their default gateway (Sonicwall) which will redirect them to pfSense.