I've put up an article on this topic that I hope will help others: see Setting Up an iOS 7 On-Demand VPN

Well, that was it.  After switching the OVPN subnet to an arbitrary 192.168.xxx.0/24 subnet the traffic is flowing properly.  Thank you so much for your help.

[image: 2v2xl4x.png]

thanks man, i fixed the issue.

http://www.freebsdonline.com/content/view/589/506/ Seems like the kind of thing we should try internally, however.

Thanks for your reply phil. I'm getting the same error messages using my mobile hotspot. And yes, I already created a WAN rule to allow traffic to port 20212. I created a WAN rule to allow ICMP on pfSense server and starting to troubleshoot the issue. Can't ping the server from the internet though. Will post back for updates.

Status > System Logs, OpenVPN tab. It isn't there for long, but they are logged there. If you forward those logs to a remote syslog server they could be retained longer.

Now I remember my reason for not wanting some shares to work across the VPN. We have a backup share where laptops automatically do backup at lunchtime (if they are turned on and on the LAN). The backup share is accessed by an automatic job on the client laptop. There are also other shares on the server that the ordinary user uses. When they go to another office, they need to use the user shares remotely across the VPN. But when the backup job starts up at lunchtime, I don't want it to succeed - and saturate the VPN with a backup to their home site. I don't think there is going to be a way to fix this with firewall rules or Windows server settings. Might have to think some more about making an DNS alias name for the server, making that alias only resolve at the home site, and making the backup job use that alias. Then it should fail when the laptop is away from its "home site". Anyway - not a pfSense issue, but may be doable with a DNS Forwarder Host Override (extra name) at the home site.

It's working now.  Seems it was a combination of things. I needed the iroutes on the server, and I also had the VPN server configuration set to "Remote Access SSL/TLS" since I was initially using this for Road Warriors, but later wanted to add a site-to-site.  Changing it to Peer to Peer gave me an option for Remote Networks on the server side that I didn't see before and once I entered the branch network in there things started working. Thanks for your help, hope the OP gets it going as well.

@marvosa: It appears you have routed setup, so why are you using Device Mode "Tap"?  You should be using "Tun". Yeah, that was a derp on my part. tap is actually correct - I was trying to get to a server bridged configuration (so I could get broadcasts working across the VPN). It was just figuring out how to do that in the "pfSense way." I could have copied my old config out of DD-WRT and the script I had written to bring everything online, but then I wouldn't have learned anything. @phil.davis: OpenVPN has its own protocol for keeping track of and retransmitting lost packets, and that has timers etc. Wow, TIL! It makes sense now that I know that.

@phil.davis: I just noticed that some of the rules you were trying had protocol TCP selected. So they were not effective, because your OpenVPN (as is normal and best practice) is using UDP. That is a bit of a trick when making new rules - the protocol field defaults to TCP, rather than "any". Jesus. How couldn't I notice. You're right and it's so obvious but somehow I managed to ignore that field when checking the rules. Should've taken a closer look at pfBlocker's rule aswell:  **IPv4 *** Nevertheless I posted this issue at OpenVPN forum also because I'd like to know what exactly this IP was doing? Does the log entry mean, the IP connected to my OpenVPN but without correct auth. data? Or is it just about the ta.key as I've read somewhere when searching for this message.

I don't understand - "push "route …"" is probably something you put in the advanced box of the server. When the client connects, the server pushes the route to the client in real-time, effectively telling the client that the server is the route to the specified subnet. There will be nothing special in the client config. But if you want the client to push a route to the server (i.e. client tell server about a subnet reachable through the client) then that is different. What are you trying to achieve? In which direction? Also, at the server end, you do not need to push route - just put all the subnets reachable through the server into the Local Network/s field.

Can someone confirm the question posed by mtisza: Assume no clients from the client specific override section are currently connected, and then a user (non-override type) connects to the VPN, what IP will they be assigned?  I'm hoping the answer is that pfsense will definitely know that 4, 8 and 12 are "reserved" for the overrides and MUST not be used. Is that how pfSense behaves? Thanks!

I second that emotion! I've been playing around with OTP using various fobs/clients, including "Google Authenticator".  Would be great to have that!

Ok, so starting OpenVPN in admin mode does let it add a route to the table: IPv4 Route Table =========================================================================== Active Routes: Network Destination        Netmask          Gateway      Interface  Metric           0.0.0.0          0.0.0.0      192.168.0.1    192.168.0.10    10         127.0.0.0        255.0.0.0        On-link        127.0.0.1    306         127.0.0.1  255.255.255.255        On-link        127.0.0.1    306   127.255.255.255  255.255.255.255        On-link        127.0.0.1    306       192.168.0.0    255.255.255.0        On-link      192.168.0.10    266     192.168.0.10  255.255.255.255        On-link      192.168.0.10    266     192.168.0.255  255.255.255.255        On-link      192.168.0.10    266       192.168.1.0    255.255.255.0    192.168.10.5    192.168.10.6    30     192.168.10.1  255.255.255.255    192.168.10.5    192.168.10.6    30     192.168.10.4  255.255.255.252        On-link      192.168.10.6    286     192.168.10.6  255.255.255.255        On-link      192.168.10.6    286     192.168.10.7  255.255.255.255        On-link      192.168.10.6    286         224.0.0.0        240.0.0.0        On-link        127.0.0.1    306         224.0.0.0        240.0.0.0        On-link      192.168.0.10    266         224.0.0.0        240.0.0.0        On-link      192.168.10.6    286   255.255.255.255  255.255.255.255        On-link        127.0.0.1    306   255.255.255.255  255.255.255.255        On-link      192.168.0.10    266   255.255.255.255  255.255.255.255        On-link      192.168.10.6    286 =========================================================================== Persistent Routes:   Network Address          Netmask  Gateway Address  Metric   255.255.255.255  255.255.255.255        On-link        1         224.0.0.0        240.0.0.0        On-link        1 =========================================================================== Pinging 192.168.10.1 or 192.168.1.1 both still time out.