Block traffic to WAN from Zywall itself

Dreadbit

Hello, I want to block the leakage of traffic to 192.168.X , 10.X and other RFC "internal" networks via WAN.
That's easy to block the traffic coming from elsewhere not Zywall itself; Policy control - from (zone)ANY to (zone)WAN where dest ip == RFC1918 group.

However, that does not work with traffic generated by USG itself, (cause USG is not in (zone)ANY).

How do I? I'd like smth like From = (zone)Zywall , but Zywall can be only destination zone.

Thanks in advance.

PeterUK

But its unlikely USG will send RFC1918 traffic out....but if you want to make sure you could put a managed switch upstream of the USG and block RFC1918 that way.   

Dreadbit

I do not need switch + port mirroring for that to see what's happening. Just traceroute to some locally unexisting RFC1918 net shows the traffic goes to defaultroute & wan.

Zyxel_Stanley

Hi @Dreadbit 

When client access to internet, the traffic of source IP address will replace as WAN IP of ZyWALL. (SNAT) 

After replaced IP, the new traffic will belong to new session those initialed by ZyWALL. If block this kind of traffic, then whole of network will with the problem.

And also, there are many services traffic will unable to work normally.

e.g. DHCP/ DNS/ ARP/ UTM service download……etc.

 

Since there are many system services will effect this kind of setting, so it doesn’t allow to set this configuration.

Dreadbit

Ok, that's my case: I have IPSEC tunnel with local side 10.0.Y.1/24 and remote side 10.0.X.1/24. Over this IPSEC tunnel I have 6in4 tunnel.

If the IPSEC tunnel gots disconnected, 6in4 (locally generated) tries to send data to 10.0.X.1. And it leaks (my *unencrypted* 6in4 traffic)  to default route to wan, because IPSEC is down.

> After replaced IP, the new traffic will belong to new session those initialed by ZyWALL

I'm sure that it does not SNAT in my case, because I have NAT rules only for selected interface.

PeterUK

You can block RFC1918 IP's with a managed switch ACL.

Zyxel_Stanley

Hi @Dreadbit

In your scenario, client’s IPv4 traffic should not forward to internet.

Since 6in4 tunnel will only route the traffic those destination traffic is IPv6.

If client IP (10.0.Y.0/24) initials IPv4 traffic and destination is 10.0.X.0/24, the device will force route the traffic into site to site VPN tunnel. But not into IPv6 tunnel.

Of cause you can create a policy route for your scenario:

It can force traffic forward into VPN tunnel even the tunnel doesn’t exist. (ZyWALL will drop the packet if tunnel doesn't exist)