Ovpn Client to Endian works! but not for all ip?

Razorjack

Hi guys, I'm John sorry if I bother you all, but I think have read online everything about this without find a real solution

this is the problem: I successfully create a VPN client to server between Endian (server) and Pfsense (client) but I can't undestand why some ip address of the remote network (server: 192.168.172/24) and some ip address of the local network (192.168.173/24 client from server) are unreachable °_°

so if with my computer 192.168.173.49 want to ping 192.168.172.99 is ok, but if i want to reach 192.168.172.20 not work! I've already checked the windows firewall and every computer can reach each other if they comunicate in the same lan, have already checked gateways on computer ethernet adapter.

same thing if I'm at the office and from 192.168.172.99 want to ping 192.168.173.36 (ilo interface of my homeserver) all works, but if I want to reach my computer 192.168.173.49 not work… what the hell....

this is my configuration, please help me if you can

(only showing relevant setting)

Home/Pfsense/Client configuration

servermode: p2p(ssl/tls)
protocol: udp ipv4 only
device: tun (also tested and same result with tap)
interface: wan
server host: my office public ip
server port: 1194
description: openvpn2office
user auth: all blank
tls config: uncheked
peer cert authority: Endian Exported CA
client certificate: Endian Exported certificate
enc Algorithm: BF-CBC 128 bit key,64 bit block
enable NCP: enabled
NCP Algorithms: AES-256-GCM and AES-128-GVM
auth digest: SHA1 (160bit)
hard crypto: no
Ipv4 tunnel network: 10.55.8.0/24
ipv4 remote network: blank but also tested with real remote network 192.168.172.0/24
compression: LZO
custom option: auth-user-pass /cf/conf/client100-auth.txt

RULE on PFSENSE:

OPENVPN inteface:
States Protocol Source Port Destination Port Gateway Queue Schedule Description
0 /1 KiB IPv4 * * * * * * none OpenVPN openvpn4office wizard

NAT on PFSENSE
Automatic Rules:
Interface Source Source Port Destination Destination Port NAT Address NAT Port Static Port Description
WAN 127.0.0.0/8 192.168.173.0/24 10.55.8.0/24 * * 500 WAN address * Auto created rule for ISAKMP
WAN 127.0.0.0/8 192.168.173.0/24 10.55.8.0/24 * * * WAN address * Auto created rule

Mappings
Interface Source Source Port Destination Destination Port NAT Address NAT Port Static Port Description Actions
WAN 127.0.0.0/8 * * 500 WAN address * Auto created rule for ISAKMP - localhost to WAN
WAN 127.0.0.0/8 * * * WAN address * Auto created rule - localhost to WAN
WAN 192.168.173.0/24 * * 500 WAN address * Auto created rule for ISAKMP - LAN to WAN
WAN 192.168.173.0/24 * * * WAN address * Auto created rule - LAN to WAN
WAN 10.55.8.0/24 * * 500 WAN address * Auto created rule for ISAKMP - OpenVPN client to WAN
WAN 10.55.8.0/24 * * * WAN address * Auto created rule - OpenVPN client to WAN

office/Endian/server configuration

auth type: psk(username/password)
cert: Self created and exported for pfsense
server port: 1194
device: tun (also tested with tap, same result)
protocol: udp
ipv4 tunnel network: 10.55.8.0/24
bridged: unchecked (want to use tunnel network)
cert configuration: same as the above
clt2clt connection: allow direct connection
forced network: 192.168.172.0/24

office/endian/user for ovpn config

username: myusername
password: mypassword (same as the file in pfsense configuration)
certificate: same as the other in endian
vpn option
force network: 192.168.172.0/24
lan behind client: 192.168.173.0/24

hope someone can find a solution... I've read about a net30 config in pfsense but I not use it
and don't know in which wall I have to crush my head

however, tunnel seems works fine, and some ip not responding thru the tunnel

I've also follow another way, assign a OPT1 interface to openvpn tunnel, create Networks Alias and create also a rule to gateway the network thru the tunnel
same result...

I think Endian config is ok becouse I have in the beginning an Endian FW in my home and all works well (with incredibly lag caused by virtualized fw) so nothing was changed in the office configuration

viragomann

Do not trust Windows firewalls! Disabling it, often does not deactivate it immediately.

For a simple test to get closer to the problem you can use the ping tool from the pfSense GUI.
Take an IP out of the office network which you can ping from a local device but not from remote. On the home pfSense go to the ping tool and enter the IP and run a ping with the default source selection. Then change the source to LAN address (the pfSense address in the 192.168.173.0/24 network) and run the ping again.
If you get responses on the first run but not on the second check the firewall and the network settings on the destination device.

Razorjack

Thanx Viragomann, I've tryed, doing a ping from Pfsense interface changed nothing, I can ping 192.168.172.99 but not 192.168.172.20 and same thing from Endian firewall, I can ping 192.168.173.36 but not 192.168.173.49 or 100

local ip of both firewall are reachable, everything in their lan are reachable by ping and I've also checked the gateway and is correct.. (have only one gateway for each network)

hard to find this problem, no entry on firewall log… I can't believe it

Razorjack

ok man, as Viragomann says do not trust Windows Firewall, so I've solved Half of the route.

now from pfsense (client) to endian (server) all works well, I can reach everythings in the office network.

but I not the inverse, Endian have a route already and works if used with another endian Firewall so I think is Pfsense that block for some reason the traffic.

have you an idea of what I need to check?

viragomann

So you also have access from a client behind pfSense to a device in the LAN behind Endian? If so the routes on both sites should be fine.
And since the firewall rule on pfSense OpenVPN interface allows any IPv4 access, it shouldn't block anything.

To troubleshoot, you can use Packet capture from the pfSense Diagnostic menu.
Take a capture on the OpenVPN interface, while you try to access a device from the other site. You should see the packets there, even if pfSense blocks them. If it doesn't block the traffic you should also see responses.
If there are no packets arriving on the vpn interface, the traffic may not be routed into the VPN tunnel on Endian.
If the packets are arriving, also take a capture on the LAN interface to see what's going on there.

Razorjack

Viragomann thankyou in advance for your help, I've done what you suggest, and if from endian network (192.168.172/24) I ping pfsense ip 192.168.173.36

packet capture see this on openvpn tunnel
20:40:43.262508 IP 192.168.172.99 > 192.168.173.36: ICMP echo request, id 1, seq 2490, length 40
20:40:43.270631 IP 192.168.173.36 > 192.168.172.99: ICMP echo reply, id 1, seq 2490, length 40

instead if I ping my computer packet capture show this

23:25:06.328269 IP 192.168.172.99 > 192.168.173.49: ICMP echo request, id 1, seq 3866, length 40
23:25:11.309302 IP 192.168.172.99 > 192.168.173.49: ICMP echo request, id 1, seq 3867, length 40
23:25:16.309808 IP 192.168.172.99 > 192.168.173.49: ICMP echo request, id 1, seq 3868, length 40
23:25:21.308759 IP 192.168.172.99 > 192.168.173.49: ICMP echo request, id 1, seq 3869, length 40
23:25:26.306973 IP 192.168.172.99 > 192.168.173.49: ICMP echo request, id 1, seq 3870, length 40

is right to suppose that the icmping pass the tunnel? why my computer not respond? is my computer? becouse if I ping everything in my home side all seems to be ok

now I'll check the lan..

ok monitoring the same ip on lan interface these are the results
23:31:11.311218 IP 192.168.172.99 > 192.168.173.49: ICMP echo request, id 1, seq 3945, length 40
23:31:16.311602 IP 192.168.172.99 > 192.168.173.49: ICMP echo request, id 1, seq 3946, length 40
23:31:21.311830 IP 192.168.172.99 > 192.168.173.49: ICMP echo request, id 1, seq 3947, length 40

monitoring instead my computer ip (192.168.173.49)
….
what the...!! what the!!!! sorry man sorry al I can't believe it... DON'T TRUST WINDOWS FIREWALL and MICROSOFT UPDATE! I can't believe it...

ok man all works perfect, windows firewall for some reason after the last windows 10 update reset all windows firewall rule... f@..k

thankyou so much Viragomann, probably I can't go so near to the solution without your help, I'm newbie of Pfsense and many of the fantastic tool it have start to know it now..

thakyou again

John

viragomann

And your computer uses pfSense as gateway?

Maybe its firewall is blocking the access.

Razorjack

Yes, my computer stay in home lan behind pfsense and use it as gateway

but there's a thing that I cannot explain… why my computer and so windows firewall let me to ping it from same subnet (another computer behind pfsense)
but refuse to answer to icmping if they come from the openvpn tunnel?

what I have to do is going to advanced firewall configuration of windows and enable every ICMPING out rule and for every rule set in advanced tab that is related to every 3 kind of zone: private,public and domain.

there's no meaning I think to do it but it's the only way to make it works, and I've tested with another computer (microserver in same subnet).

viragomann

That ping comes from the remote LAN not the OpenVPN tunnel, but that won't make any difference for the Windows firewall.
Since the network is not assigned to the computer, Windows sees it as "public".

If you don't want to modify all your computers firewalls you can also get it work by natting the source addresses to the pfSense LAN IP. So the access will seem to come from the local subnet and Windows will trust it. But if you do that, you don't see the real origin IP address on the destination device.

Razorjack

that's the answer, I think for a little home network change windows firewall is enough, otherwise I think better looking to trust the remote subnet to make the windows firewall setting easyer

viragomann

The NAT method is also called masquerading and that puts it in a nutshell. A Windows firewall by default only trusts devices in its own network and with this method it seems that the access comes from its own network segment.

To do this is an easy workaround as long as you have no need to determine the source device on the destination device.
So, in my opinion, its sufficient for home use, but in a business environment I would prefer the routing method and configure the firewalls to allowing access as needed.