OpenVPN. Connected. Hex can ping, local pc's can't.

RouterOS General
1

I’m fairly new back to mikrotik after about a 5+ year stint of using other devices. So I’m relearning all over again. I have a openvpn site to site going from a hex (client) to pfsense (server). Both on newest versions.

I can ping the pfsense from terminal on the hex.
I cannot ping the pfsense from a pc behind the hex.
Nothing on the pfsense side can ping anything on the hex side.


PC (192.168.1.9) → hex (192.168.1.1) → INTERNET ← Pfsense (192.168.140.1)

Trace route from PC side shows it going thru router.lan 192.168.1.1 and then that’s it.


For the most part this hex is mostly default except the openvpn, and basic quick setup. I’ve set a firewall rule to allow all just for testing purposes. I’m wondering if I need to setup nat or mangle with something.

I need to be able to ping all devices on the clients side from the systems on the pfsense’s subnet.

2

If you were on the same subnet, I would say you are missing arp-proxy on your LAN interface - very typical situation.
However, you are saying that there is different subnet on each side. That suggest you don’t have correct routes and/or firewall is blocking the communication.
Could you share more info about your setup? e.g. interfaces, IP addresses (including netmask) and routes on both hex and pfsense? Also firewall config (both filter and NAT) could help with pointing out the issue.

3

Firewall on both sides are wide open set to allow everything on all interfaces for the moment.

hex (192.168.1.1/24)
pfsense (192.168.140.1/24)
lan interface on hex arp was set to “enabled” now it’s set to “proxy-arp”

I can actually ping from hex itself only, to everything on the pfsense and behind it.

/ip firewall filter
add action=accept chain=input
add action=accept chain=input in-interface=ovpn-out1
add action=accept chain=output out-interface=ovpn-out1
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
    ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
    ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
    connection-state=established,related
add action=accept chain=forward comment=\
    "defconf: accept established,related, untracked" connection-state=\
    established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
    connection-state=invalid
add action=drop chain=forward comment=\
    "defconf:  drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
    connection-state=new in-interface-list=WAN
add action=accept chain=input protocol=icmp
add action=accept chain=input connection-state=established
add action=accept chain=input connection-state=related
add action=drop chain=input in-interface=ether1
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" \
    ipsec-policy=out,none out-interface-list=WAN
add action=accept chain=srcnat dst-address=192.168.140.0/24 src-address=\
    192.168.1.0/24
add action=masquerade chain=srcnat out-interface=ether1

^ firewall rules on my hex.

For some reason my routes are only exporting my disabled routes but heres how it is:

0.0.0.0/0 gw: wan ip on eth1
my.gateway.ip gw: eth1 reachable
172.16.33.0/24 gw: ovpn-out1 reachable
192.168.1.0/24 gw: bridge1 reachable
194.168.140.0/24 gw: 172.16.33.1 reachable ovpn-out1.

4

this one is BIG security issue. Your first rule literary say “accept any packet from everywhere, including wan”.


This is unnecessary, because there is no “drop” rule on output. Implicitly, every output will be allowed anyway.

Since you don’t have explicit “drop all” forwarding rule, I guess it is not firewall-filter issue on hex.

I assume you don’t have a route on PFSense, which would lead to 192.168.1.0/24 and pfsense is aware only of its WAN, LAN (192.168.140.0/24) and OVPN (172.16.32.0/24).
If that is true, you can either manually add this route to PFSense (that might be challenging if hEX gets someday different IP on OVPN interface) or you can add masquerade rule to your hEX:

/ip firewall nat add action=masquerade chain=srcnat out-interface=ovpn-out1

Without complete set of info from both devices as asked previously, I can’t guess much more (and obviously my assumption may be wrong).

In overall, you can easily debug this with packet sniffer and a bit of network knowledge. All you need to do is figure out where the packet gets lost by looking at different interfaces/links. (and that is typical use-case for packet sniffer)

5

https://imgur.com/a/FM3ngQO

Thanks for being patient with me.

Here are the routes from the pfsense side.

I added your masq and no positive changes happened.

Unfortunately I’m not a wire shark expert either.

6

I dropped the accept output all rule in the firewall and now I can ping from the pc to anything on the pfsense side.

However I still cannot ping from anything on the pfsense side to the hex side. :confused:


This is cake when it’s pfsense to pfsense. Takes me 2 seconds to get this going. But mikrotik throws a bit of complication into this.

7

I don’t know whether you use a src-nat or masquerade rule in /ip firewall nat referring to the /interface ovpn-client, but lets’s suppose you don’t.

In general, there is a hidden surprise in openvpn - to access subnets on client side, it is not enough to set up, at server side, the corresponding routes with the client’s own address assigned by openvpn as gateway; on top of that, you have to tell that separately also the openvpn server process using the iroute directive in openvpn.conf. See further details here.