Little bit lost

pff

I have two pfsense boxes connected via openvpn as ssl/tls p2p. link is connecting that's not the problem.
tunnel is 10.200.1.0/24
server is 10.200.1.1, lan is 10.20.1.0/24
client is 10.200.1.2, lan is 10.10.1.0/24
there are other networks but i won't go into that.

ok. from client on either lan i can ping respective pfsense boxes.
from client pfsense i can ping server pfsense box
from server pfsense i CANNOT ping client pfsense box
from client on client pfsense i CANNOT ping server pfsense

firewall>rules>openvpn has rule of "ipv4 *********** etc" on both client and server.
routes table looks reasonable to me, the 'remote' lan routes to remote tunnel and then remote tunnel routes to 'ovpnc1' which i assume is openvnc something.

so is there something obvious i'm missing? not making much sense to me. thanks.

marvosa

Post the server1.conf from the server and the client1.conf from the client.

pff

server:

dev ovpns1
verb 11
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-256-CBC
auth SHA1
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 192.168.0.2
tls-server
server 10.200.1.0 255.255.255.0
client-config-dir /var/etc/openvpn-csc/server1
ifconfig 10.200.1.1 10.200.1.2
tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'server' 1"
lport 1194
management /var/etc/openvpn/server1.sock unix
push "route 10.20.1.1 255.255.255.0"
route 10.10.1.1 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
topology subnet

client:


dev ovpnc1
verb 1
dev-type tun
dev-node /dev/tun1
writepid /var/run/openvpn_client1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-256-CBC
auth SHA1
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 192.168.0.11
tls-client
client
lport 0
management /var/etc/openvpn/client1.sock unix
remote *server wan ip* 1194
route 10.20.1.0 255.255.255.0
ca /var/etc/openvpn/client1.ca 
cert /var/etc/openvpn/client1.cert 
key /var/etc/openvpn/client1.key 
tls-auth /var/etc/openvpn/client1.tls-auth 1
resolv-retry infinite
route-nopull

I set this up through web gui, the 'locals' are the pfsense ip on the modem network. if that makes sense. i guess thats to be expected?

marvosa

Are you using a PKI or Shared Key setup?

I can see you're double NAT'd on both sides, which is an extra complication in and of itself. You may end up needing static routes on your edge routers.

push "route 10.20.1.1 255.255.255.0"

This line is incorrect on your server config. This line should read -> push "route 10.20.1.0 255.255.255.0". Which tells me you're probably running a PKI setup and entered your network wrong on the IPv4 Local network(s) line. It's should be 10.20.1.0/24
route 10.10.1.1 255.255.255.0

This line is also incorrect on your server config. This line should read -> route 10.10.1.0 255.255.255.0. Go to the IPv4 Remote network(s) line on your server config and enter 10.10.1.0/24
route-nopull

The client-side has Don't add/remove routes checked in the client config. Which means the client is denying routes pushed from the server. I'm not sure how this was expected to work given your setup.

In addition to the corrections above, if you're using a PKI setup, you'll need an iroute statement on your CSO tab so the server knows that 10.10.1.0/24 is behind your client's specific peer address

Honestly, unless you're planning on scaling to 7+ tunnels, I'd recommend moving to a shared key setup.

pff

PKI.
Is the NAT an issue? the link establishes successfully.
Thank you i have corrected the networks.
nopull was added because it turned the client pfsense into a black hole, necesary for me to post here. perhaps i should have mentioned! but fixing route ip has solved this, thanks again.

i don't understand the requirement of CSO, the route exists in the route table already, 10.10.1.0/24 -> 10.200.1.2.

clearly i should be spending my time reading manuals.

marvosa

Is the NAT an issue? the link establishes successfully.

As long as you have your local port forwarded to PFsense, you should be fine, but I have read on other forums that if everything appears to be configured correctly and still doesn't work that you may have to create a static route on your edge router for the tunnel network. However, that may have been limited to remote access configs… I just don't remember. At any rate, it's moot since you're up and running.

nopull was added because it turned the client pfsense into a black hole, necesary for me to post here. perhaps i should have mentioned! but fixing route ip has solved this, thanks again.

This is an explanation of the route-nopull directive from the OpenVPN manpage:
"When used on the client, this option effectively bars the server from adding routes to the client's routing table, however note that this option still allows the server to set the TCP/IP properties of the client's TUN/TAP interface."

My assumption is your setup is working because you've defined a remote network on the client-side. Otherwise, the client would deny pushed routes and there would be no routing to the server-side LAN over the tunnel.

i don't understand the requirement of CSO, the route exists in the route table already, 10.10.1.0/24 -> 10.200.1.2.

I could be wrong, but my guess is things are working because there's only 1 tunnel and 1 peer, so there's no where else for the traffic to go. However, imagine if there were 8 tunnels… how would the system know which peer to send each respective LAN traffic to? Per the wiki, that's where the CSO tab comes in.

Skimming over the wiki -> https://doc.pfsense.org/index.php/OpenVPN_Site-to-Site_PKI_(SSL), it looks like a typical setup is not to define much of anything on the client-side and control everything from the server. In which case, configuring CSO options per tunnel would be necessary.

pff

Thanks, this makes sense of course for multiple clients and cetralising configuration sounds useful.

The openvpn link is established however that was not really the issue,
I still have no connectivity between clients other than the pfsense running openvpn client -> pfsense running openvpn server.

marvosa

@pff:

Thanks, this makes sense of course for multiple clients and cetralising configuration sounds useful.

The openvpn link is established however that was not really the issue,
I still have no connectivity between clients other than the pfsense running openvpn client -> pfsense running openvpn server.

I'm a bit confused… because in your last post you stated:

nopull was added because it turned the client pfsense into a black hole, necesary for me to post here. perhaps i should have mentioned! but fixing route ip has solved this, thanks again.

Did we regress from that statement? Was it ever working? If you're testing with windows clients, I would disable the software firewall on both ends and re-test… to verify windows firewall is not interfering. Then reassess what is and what is not working.

pff

Sorry i should have been more clear,

with the wrong net and without nopull everything was dropped.
adding nopull was necessary to access internet but didn't fix vpn issues.
correcting net meant nopull option could be removed without breaking internet access.