Site to Site OpenVPN - network share client's net
-
Hello everybody, i have a problem with my pfSense in connection with the OpenVPN function.
First the problem, then my current network setup for better understanding.
Problem is, i can't map network drive in the lan network behind the openvpn client.
It's a site to site VPN connection and i can ping every host on any site.
The network looks like follows:
192.168.12.0 /24 network of a ddwrt router on it a VPN-server. The router is directly connected with the ISP gateway router of the network 192.168.100.0 /24.
On the client site the same configuration, only reversed. ISP gateway router 192.168.1.0 /24 and behind of it the pfSense as the openvpn client with the net of 192.168.2.0 /24.Because i can ping every host and i have a stable, full vpn connection i can't understand, what's wrong or what I have to do to map the network drives?
The only network which i can map is the server site lan network from the client site lan. But i want to map the other way arround.
I know this are different subnets but for openvpn connection, it's normal. Oh, and the firewall of the host which I want to map is off.
NAT or firewall problem … ideas? -
I map network drives through vpn all the time.. Its sure and the hell not going to be fast if you have any serious latency between sites..
So what error do you get when you try and map? Can you do a simple net view?
net view \IPaddress
If your wanting to use name you would have to make sure dns is working through your vpn and use FQDN, etc. Do you have "Enable NetBIOS over TCP/IP" in the vpn server setup checked?
-
I map network drives through vpn all the time.. Its sure and the hell not going to be fast if you have any serious latency between sites..
So what error do you get when you try and map? Can you do a simple net view?
net view \IPaddress
If your wanting to use name you would have to make sure dns is working through your vpn and use FQDN, etc. Do you have "Enable NetBIOS over TCP/IP" in the vpn server setup checked?
Latency could be a problem but i think it's not, because in one direction it works and the latency until the conncection is established is ok.
net view \ip of the target machine behind the client doesn't work
Currently I only want to map the drive over IP. If that works, i take care of the dns resolution.
On the vpn server setup, there is no possibility to check NetBIOS over TCP/IP. -
We need a better visual of your topology. Here's what I've gathered from your OP:
Server-side ISP Gateway -> (192.168.100.0/24) DDWRT (192.168.12.0/24) –----> OpenVPN Tunnel <------- (192.168.2.0/24) PFSENSE (192.168.1.0/24) <- Client-side ISP Gateway
Is this accurate? If not, please post an accurate network map.
So, both sides are double NAT'd? Since the tunnel is up, I'm presuming all of the appropriate ports have been forwarded on the edge devices?
Before we go much further, please post the configs from both ends.
-
Is this accurate?
Yes, it's correct.
Here are the configs of the client and server:
Server:
Startup: #!/sbin/bash test -d /tmp/openvpn || mkdir /tmp/openvpn test -d /tmp/openvpn/ccd || mkdir /tmp/openvpn/ccd echo "iroute 192.168.2.0 255.255.255.0" > /tmp/openvpn/ccd/name of the the client cert.file Firewall: iptables -t nat -A POSTROUTING -o eth0 -s 172.16.2.0/24 -j SNAT --to 192.168.100.79 iptables -I FORWARD 1 --source 192.168.12.0/24 -j ACCEPT iptables -I INPUT 1 -p udp --dport 1155 -j ACCEPT iptables -I INPUT 3 -i tun0 -j ACCEPT iptables -I FORWARD 3 -i tun0 -o tun0 -j ACCEPT iptables -I FORWARD -i br0 -o tun0 -j ACCEPT iptables -I FORWARD -i tun0 -o br0 -j ACCEPT iptables -I FORWARD -j ACCEPT Server-Config: port 1155 proto udp dev tun0 ca /tmp/openvpn/ca.crt cert /tmp/openvpn/cert.pem key /tmp/openvpn/key.pem dh /tmp/openvpn/dh.pem server 172.16.2.0 255.255.255.0 push "route 192.168.12.0 255.255.255.0" keepalive 10 120 comp-lzo persist-key persist-tun verb 3 management localhost 14 script-security 3 syslog topology subnet client-config-dir /tmp/openvpn/ccd route 192.168.2.0 255.255.255.0 172.16.2.1 client-to-client tun-mtu 1500 fragment 1280 mssfixClient:
Server host: dyndns domain Tunnel Network 172.16.2.0/24 Remote Network 192,168,12,0/24 Topology Subent Type-of-Service Set the TOS IP header value of tunnel packets to match the encapsulated packet value. ns-cert-type server; float; script-security 3; tun-mtu 1500; fragment 1280; mssfix;Routing Tables
Server:
0.0.0.0 0.0.0.0 192.168.100.1 UG 0 WAN
169.254.0.0 255.255.0.0 0.0.0.0 U 0 LAN & WLAN
172.16.2.0 255.255.255.0 0.0.0.0 U 0 tun0
192.168.2.0 255.255.255.0 172.16.2.1 UG 0 tun0
192.168.12.0 255.255.255.0 0.0.0.0 U 0 LAN & WLAN
192.168.100.0 255.255.255.0 0.0.0.0 U 0 WANClient:
default 192.168.1.1 UGS 288899 1500 igb0 127.0.0.1 link#7 UH 9794 16384 lo0 172.16.2.0/24 172.16.2.1 UGS 0 1500 ovpnc1 172.16.2.1 link#8 UH 0 1500 ovpnc1 172.16.2.2 link#8 UHS 0 16384 lo0 192.168.1.0/24 link#1 U 4435650 1500 igb0 192.168.1.104 link#1 UHS 0 16384 lo0 192.168.2.0/24 link#2 U 25865210 1500 igb1 192.168.2.1 link#2 UHS 0 16384 lo0 192.168.12.0/24 172.16.2.1 UGS 1048 1500 ovpnc1 -
There is nobody who can help at this problem?
-
"Remote Network 192**,168,12,**0/24
That sure and the F is not right!
-
I think it`s better you read here:
https://openvpn.net/index.php/open-source/documentation/howto.html#scope -
Also this..
Topology Subent
WTF.. Dude either post up your configs or don't.. This seems like your manually typing out shit?
If your client side is pfsense. The post up its client side config.. either with a screnshot (best) or the actual config file..
Do a traceroute from each end. You say you can devices from each end in both directions.. If that is the case and file sharing is not working then its on the box sharing not allowing the remote network most likely.
-
-
Your server is configured more like what we'd typically see in a remote access server vs. a site to site config. This would be much more straight forward if PFsense was the server. If you're planning on keeping DDWRT as the server, you may have to consult the OpenVPN forums for tuning your config. I can't confirm whether those iptables statements are valid… especially that NAT statement.
-
route 192.168.2.0 255.255.255.0 172.16.2.1
This is incorrect. The server takes the first IP on the tunnel network, so you should be routing traffic destined for 192.168.2.0/24 to the virtual IP on the remote end of the tunnel network… most likely 172.16.2.2, but you'll need to verify that.
-
On the client-side config, I don't know what that is, but I can say with absolute certainty that what you have displayed is NOT a client config from PFsense. Please post the client1.conf from PFsense
-
