Openvpn, lan and wan trouble
-
Hi!
Ive got openvpn running om my pfsense box which has a wan, lan and a optiona (dmz) interface.
The lan and dmz interface rules allow the appropriate subnet access to anything "allow dmz > any" "allow lan > any"
I read that the openvpn subnet is allowed everywhere without the need for rules, so i didnt make any rules either.The problem im having is that i cant from the openvpn subnet acccess internet or the lan subnet, only the dmz net is avalible.
Allthough hosts from the lan net can ping the openvpn hosts, the openvpnhosts cant ping the lan hosts :-\My default route gets set correctly to my tun0 interface on the openvpn client machine
default 13.37.2.5 0.0.0.0 UG 0 0 0 tun0So all traffic towards the internet is atleast going out to the openvpn net gateway on my pfsense box.
Ive set the Local network configuration to 13.37.0.0 /24
and i push the route 13.37.1.0 /24 for my dmz netAllthoguh this is the only entry i get in my routing table on the client.
13.37.0.0 13.37.2.5 255.255.255.0 UG 0 0 0 tun0Which is strange since i can access 13.37.1.0 /24 net, but not the 13.37.0.0 /24 net "Which is in my routing table"…
Any help or comments would be nice.
-
Did you look at the openVPN log on the server and the client?
You say you added the additional route to the custom options, but are they in the right format?
-
The things i push looks as follow
push "route 13.37.1.0/24";push "dhcp-option DNS 13.37.1.1";push "dhcp-option DOMAIN myrealdomain.com"client log
May 7 10:07:34 suse NetworkManager: <debug>[1273219654.105069] write_to_netconfig(): Writing to netconfig: DNSSERVERS='13.37.1.1'#012
May 7 10:07:34 suse NetworkManager: <info> Clearing nscd hosts cache.
May 7 10:07:34 suse NetworkManager: <info> VPN connection 'openvpn_1' (IP Config Get) complete.
May 7 10:07:34 suse NetworkManager: <debug>[1273219654.107123] run_netconfig(): Spawning '/sbin/netconfig modify –service NetworkManager'
May 7 10:07:34 suse NetworkManager: <debug>[1273219654.115685] write_to_netconfig(): Writing to netconfig: DNSSEARCH='myrealdomain.com myrealdomain.com localdomain.se'#012
May 7 10:07:34 suse NetworkManager: <debug>[1273219654.115841] write_to_netconfig(): Writing to netconfig: DNSSERVERS='13.37.1.1'#012
May 7 10:07:34 suse NetworkManager: <info> Clearing nscd hosts cache.
May 7 10:07:34 suse NetworkManager: <info> Policy set 'osund' (tun0) as default for routing and DNS.
May 7 10:07:34 suse NetworkManager: <info> VPN plugin state changed: 4
May 7 10:07:34 suse nm-dispatcher.action: Script '/etc/NetworkManager/dispatcher.d/netcontrol_services' exited with error status 127.server logs
May 7 10:11:40 router openvpn[5595]: TCPv4_SERVER link local: [undef]
May 7 10:11:40 router openvpn[5595]: TCPv4_SERVER link remote: X.X.X.X:38136
May 7 10:11:42 router openvpn[5595]: X.X.X.X:38136 [user1] Peer Connection Initiated with X.X.X.X:38136
May 7 10:12:08 router openvpn[5595]: Re-using SSL/TLS context
May 7 10:12:08 router openvpn[5595]: TCP connection established with 127.0.0.1:28872
May 7 10:12:08 router openvpn[5595]: TCPv4_SERVER link local: [undef]
May 7 10:12:08 router openvpn[5595]: TCPv4_SERVER link remote: 127.0.0.1:28872
May 7 10:12:08 router openvpn[5595]: 127.0.0.1:28872 WARNING: Bad encapsulated packet length from peer (29556), which must be > 0 and <= 1559 – please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attemping restart…]
May 7 10:12:08 router openvpn[5595]: 127.0.0.1:28872 Connection reset, restarting [0]The only thing going wrong is the clients netcontrol_services script, and the server complains about the mtu, but the connection works just as well.</info></info></info></debug></debug></debug></info></info></debug>
-
Your format of the push is wrong.
It has to be:
push "route 13.37.1.0 255.255.255.0"
-
Solved the problem with openvpn net not being able to connect out to the internet, i automatic nat , when changing to manual and adding all my subnets, the vpn networks outbound traffic to the web started working.
Still stuck on that darn openvpn net > lan , and a lan host can still ping the openvpn client, but not the other way around…
Ah! now i get the route correct.
13.37.1.0 13.37.2.5 255.255.255.0 UG 0 0 0 tun0
13.37.0.0 13.37.2.5 255.255.255.0 UG 0 0 0 tun0but i still cant access the hosts on 13.37.0.0 /24 net :-\
-
You're using public ip addresses that are registered to Xerox Corporation on your networks, any reason for that? I would change all those 13.x.x.x addresses to 10.x.x.x just to be sure there's no ill effects from using public ip addresses where private rfc1918 addresses would be more appropriate.
-
Well the reason is a bit nerdy, the two first octets read 13.37 = 1337 = leet ;)
I read somewhere that unchecking "Block private networks" on the wan interface could help, i tried it with little hope and sure enought it didnt do any good, this problem should be from the tun interface on the pfsense box and the lan interface, not involving wan at all.
I dont think that the address scheme has anything to do with the problem since i can reach 13.37.1.0 net but not 13.37.0.0 , even though i have routes and the nets are class C nets, ill try capturing some packets and look more closely at the logs.
If nothing else helps ill change the to a 10.x.x.x network..
-
Few things to check:
Can you reach the LAN gateway address from the client when the vpn connection is open?
When connecting to hosts on the LAN make sure they don't have firewall of their own that would block traffic from (their point of view) an unknown network.
Are the hosts on the LAN using pfSense as their default gateway or is there another gateway on the LAN net?
-
Yupp, i can ping 13.37.0.1 which is the gateway for the Lan.
The machine im testing against has the firewall turned off.
Chain INPUT (policy ACCEPT)
target prot opt source destinationChain FORWARD (policy ACCEPT)
target prot opt source destinationChain OUTPUT (policy ACCEPT)
target prot opt source destinationThe hosts on the lan has the pfsene lan interface 13.37.0.1 as their gateway.
The pfsense box is the only routing machine on my network, combining lan,dmz,wan and openvpn net.
Here is the traceroute from the client to machines on dmz resp lan net.
Dmz machine 13.37.1.4
1: 13.37.2.6 (13.37.2.6) 0.092ms pmtu 1500
1: 13.37.2.1 (13.37.2.1) 47.907ms
2: 13.37.1.4 (13.37.1.4) 19.079ms reached
Resume: pmtu 1500 hops 2 back 2Lan machine 13.37.0.5
1: 13.37.2.6 (13.37.2.6) 0.069ms pmtu 1500
1: 13.37.2.1 (13.37.2.1) 18.711ms
2: no replySo it looks like the openvpn gateway adress is the last to respond in the Lan case, but cant forward the packet out on the lan interface.
Something gotta be different with the lan and dmz interfaces, since dmz got no problem at all with the openvpn net.
-
Did you make sure that the client you try to ping has no firewall active?
-
yupp, tried from two different hosts aswell. same prob
-
Can you do a tcp dump on the LAN interface?
-
i filtered packets from 13.37.2.6 which is the openvpn client im currently running ssh to in order to make a connection from 13.37.2.6 to 13.37.0.5 via ssh.
sadly the only traffic showing up is my ssh session from my own host inside on the lan at 13.37.0.2 , nothing shows for the 13.37.2.6 vpn host trying to make the ssh connection to 13.37.0.5..its a one way street , since all connection from lan > openvpn is successfull but not the other way around, and i have no access-lists to fiddle with either :(
one thing that caught my attention is if the nat only works one way, lan traffic gets nated towards all other interfaces, but the tun0 inteface maybe dont have permission to starta a nat against the lan interface for some reason? , its pretty far fetched since ive read that no configuration of rules or nat should have to be done, and plus the nat towards dmz net works fron the tunnel.
-
After some reading i turned off captive portal… and now it works :)
Allthough captive portal is a nice feature im woundering if its supposed to behave this way or if its a bug?
Kinda want both openvpn > lan and captive portal to work.
