Hi, are you pinging Windows-based end-devices? If so, do note that Windows firewall (or most 3rd party firewalls) drop incoming traffic from non-LAN subnet by default. So just to visualize it, if you start ping with a source address of 192.168.2.6 [in the IP header] towards destination IP address of 192.168.9.9, then Windows would drop such packet by default, because the subnet differs.
Anyway, if it’s not the firewall thing, I’ve got a random thought in terms of router config - could you try adding a traffic rule to allow forwarding from WAN zone to LAN zone when source address is 192.168.2.0/24?
Configure traffic rule at Network > Firewall > Traffic Rules
Rule should look something like this:
Enable - yes
Name - anything you want
Restrict to address family - IPv4
Protocol - ICMP
Source zone - WAN
Source address - 192.168.2.0/24
Destination zone - Any zone (forward)
Action - accept
You can add more granular config such as destination address or port, but for testing purposes I’d avoid overcomplicating the configuration. Test connectivity with ping afterwards - if you can ping devices your RUT240’s LAN devices after adding this firewall rule (and you’re 100% positive that end-devices’ firewall is not dropping the traffic) then you may consider adding similar rule for TCP+UDP protocol so that you may actually reach services that you’d like to.
P.S. If RUT240 is not in a remote location or production environment, it’d probably be for the best to upgrade its firmware, unless you have a very specific reason to run current firmware. The one you’re running is considered a legacy firmware and, as far as I know, it is no longer maintained (or at least not as actively).
P.P.S. If you decide to upgrade firmware before adding firewall rule, do so. It might be that you won’t need any additional config once you perform the firmware upgrade. However, this wouldn’t help anyhow against the end-host firewall issue I mentioned firsthand.
P.P.P.S. If the firewall rule doesn’t help, I’d recommend deleting it (to keep things clean).
Thank you, that was the cause. It was a windows-based end-device so I deactivated its firewall and it works like magic. Is there a way to masq the traffic incoming from IPSec VPN?
As for the masq thing, you could probably try masquerading it with a custom firewall rule such as this:
iptables -t nat -A zone_lan_postrouting -s 192.168.2.0/24 -o br-lan -m policy --dir out --pol ipsec -j ACCEPT
iptables -t nat -A zone_lan_postrouting -s 192.168.2.0/24 -o br-lan -j MASQUERADE
Try to config these two lines at Network > Firewall > Custom rules. I’ve personally not tried this before so it might not work on first attempt (I don’t have a device to test it unfortunately), but following the iptables logic and some strongSwan assistance, it should translate any source address from 192.168.2.0/24 subnet only if it matches IPsec policy, to the IP address of br-lan interface, if the direction is outbound (from Sophos towards RUT br-lan).
You might need to modify the interface “br-lan” interface name, because I just took the default.
If that doesn’t work, try this instead:
iptables -t nat -A zone_lan_postrouting -s 192.168.2.0/24 -d 192.168.9.0/24 -A zone_lan_postrouting -j MASQUERADE
If none of these two methods work, could you please post the output of iptables -t nat -L -n -v and ip link from CLI? I could try to adapt syntax to your router config, in case it’s needed.
