Routed Client Experiment #1: Is this a Routed Client?


#1

Router: Linksys WRT1900ACS
OpenWrt LEDE 17.01.5

RC1b-800x600

NOTE: In the above the 2NET radio is a dedicated point-to-point link to 1NET and provides absolutely no wireless AP access to 2NET in this scenario.

BACKGROUND

After running into some erroneous code in OpentWrt documentation (now resolved, see Routed Client Doc Erroneous?) and other problems with fuzzy documentation elsewhere I gave up trying to set up a Routed Client via the SSH command line and went back to trying to "fake it" using LuCI.

Everything was stripped down to "bare bones" using one radio (2.4GHz) as a point to point link and deleting every interface except for a static LAN configuration. After joining and an establishing a client WWAN, suddenly everything was working (and I really do not know why... yet).

The two big questions I have are these --

  1. Is this set up a Routed Client? If yes, what flavor?
  2. Everyone can see everyone on each LAN. How should I modify the default firewall settings (which I did not touch) so that ...
    2a) No host on either the 1NET or the 2NET can see each other
    2b) The 2NET has access to 1NET's Internet connection
    2c) Lastly (to be implemented later), allow one host on 1NET and one host on 2NET to communicate for sharing files.

I have provided the pertinent configuration files that resulted from my LuCI setup and was hoping that some knowledgeable person might look them over and give me some answers and tips, especially with simplifying the config files (for instance, I have no need for anything IPv6) and how to handle the firewall settings.

I don't really expect any definitive answers as this is a lot to ask. Nevertheless I am posting it anyway.

Pertinent Configs --

root@LEDE:~# cat /etc/config/network

config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'

config globals 'globals'
option ula_prefix 'fd99:bda3:95c5::/48'

config interface 'lan'
option type 'bridge'
option ifname 'eth0'
option proto 'static'
option netmask '255.255.255.0'
option ip6assign '60'
option ipaddr '192.168.2.1'

config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'

config switch_vlan
option device 'switch0'
option vlan '1'
option ports '0 1 2 3 5'

config switch_vlan
option device 'switch0'
option vlan '2'
option ports '4 6'

config interface 'wwan'
option _orig_ifname 'wlan1'
option _orig_bridge 'false'
option proto 'static'
option ipaddr '192.168.1.2'
option netmask '255.255.255.0'
option gateway '192.168.1.1'
option dns '209.244.0.3 209.244.0.4'

root@LEDE:~# cat /etc/config/wireless

config wifi-device 'radio0'
option type 'mac80211'
option channel '36'
option hwmode '11a'
option path 'soc/soc:pcie-controller/pci0000:00/0000:00:01.0/0000:01:00.0'
option htmode 'VHT80'
option disabled '1'
option country 'US'

config wifi-device 'radio1'
option type 'mac80211'
option hwmode '11g'
option path 'soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0'
option htmode 'HT20'
option country 'US'
option disabled '0'
option channel '6'

config wifi-iface
option network 'wwan'
option ssid '1NET'
option device 'radio1'
option mode 'sta'
option bssid 'aMACaddress'
option encryption 'psk2+ccmp'
option key 'obscuredbyclouds'

config rule
option name 'Allow-ICMPv6-Input'
option src 'wan'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
list icmp_type 'router-solicitation'
list icmp_type 'neighbour-solicitation'
list icmp_type 'router-advertisement'
list icmp_type 'neighbour-advertisement'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'

config rule
option name 'Allow-ICMPv6-Forward'
option src 'wan'
option dest '*'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'

config rule
option name 'Allow-IPSec-ESP'
option src 'wan'
option dest 'lan'
option proto 'esp'
option target 'ACCEPT'

config rule
option name 'Allow-ISAKMP'
option src 'wan'
option dest 'lan'
option dest_port '500'
option proto 'udp'
option target 'ACCEPT'

config include
option path '/etc/firewall.user'


#2

Yes. If the generic AP has a static back route to 192.168.2.x via 192.168.1.30 (the wwan ip) then it is a fully routed client. If the OpenWrt router masquerades, then it is a natted (routed) client.

The former would be the preferable solution, the latter should only be used if it is not possible to set static routes on the generic AP (either due to limitations or lack of access) as it would result in a double-NAT situation.

You cannot really prevent ethernet client - to - ethernet client communication as this is typically switched and happening "beneath" the firewall, in most cases not even reaching the router itself.

You can however prevent all hosts in 1NET to access anything in 2NET by setting the INPUT and FORWARD policies of the WWAN's associated firewall zone (typically WAN) to REJECT or DROP.

To filter 2NET->1NET traffic you need to declare two custom traffic forward rules (not to be confused with a port forward):

  1. A rule which from zone LAN towards zone WAN allows any traffic for any protocol destined to 192.168.1.1
  2. A rule which from zone LAN towards zone WAN disallows any traffic for any protocol destined to 192.168.1.0/24

The first rule represents an explicit exception allowing access to 192.168.1.1 (the internal facing part of the internet gateway) while the 2nd rule disallows access any other 192.168.1.* IP.

Note that this solution is not really watertight as there's various ways in which traffic may still leak (broadcasts, different IP ranges, IPv6 which we didn't even consider yet etc).

This is essentially achieved by the "accept 192.168.1.1" rule above

This depends on whether you have a fully routed or a double natted client. In the former case you merely need to add one further traffic forwarding rule which for src WAN, dest LAN allows traffic towards the IP of the NET2 host you want to share files with. In the latter double NAT case your only solution would be adding a port forward on the OpenWrt router which directs specific protocol/port combinations to the 2NET target machine.


#3

Just to make sure I am being clear, what I desire is that all hosts (wired or wireless) on 1NET may communicate with each other but cannot communicate with any host on 2NET (wired or wireless with an added 2NET AP) and vice-versa unless I specify a connection across. So, evidently, the traffic forward rules are what I need to apply first to make this work, but I don't really understand them yet.

Is there a way to completely kill IPv6? The provider does not use it and I do not need it and the complexity it adds.

I would like to put a MAC filter on the 2NET Routed Client so that the radio only allows traffic from the 1NET radio and no other. Is that possible in OpenWrt?

Unfortunately the 1NET router has no facility for setting static routes, however I could add an AP to 1NET that can handle static routes.

I have extra n routers loaded with DD-WRT or OpenWrt and an unused WAN port on the 192.188.2.1 2NET router that I might might be able to connect to an AP with a WAN port and get controlled isolation that way. WAN port to WAN port (?)

There must be some topology where I can completely isolate 1NET and 2NET (except for 2NET having 1NET's Internet access) by putting another router in between somewhere?

Any ideas anyone?


#4

You can add a static route directly on the client (PC) itself


#5

For security you can create a "guest" network on router 2. Users of this network will have only the Internet. They will be firewalled off from making any access to your routers and LAN devices. This is good for public guests and/or IoT devices that you don't trust.

The firewall rules to do that look something like this. This is deployed on router 2. You don't need to set anything on router 1, router 2 just looks like a simple client to it.

# in /etc/config/firewall
# IoT configuration.  The IoT network can only reach the Internet.
#  It is blocked from all LAN devices except the DHCP and DNS service
#  on the router.
config zone
	option name 'iot'
	option network 'iot'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	
config rule
	option target 'ACCEPT'
	option src 'iot'
	option name 'IOT-DHCP'
	option family 'ipv4'
	option proto 'udp'
# DHCP requests are input to port 67
	option dest_port '67'

config rule
	option src 'iot'
	option proto 'tcp udp'
	option name 'IOT-DNS'
	option family 'ipv4'
	option dest_port '53'
	option target 'ACCEPT'

# This denies the IoT any local ports of the router (especially http and ssh), other than the 
#  DHCP and DNS which are explicitly allowed above.
config rule
	option enabled '1'
	option name 'Deny-IOT-Local'
	option src 'iot'
	option target 'REJECT'

# This will deny everything in your LAN, if you are forwarding to the LAN
#  because the router does not have a direct WAN.	
config rule
	option src 'iot'
	option proto 'all'
	option dest_ip '192.168.0.0/16'
	option target 'REJECT'
	option name 'Deny-IOT-Upstream'
	option dest '*'

# This must be after everything else.
config forwarding
	option src 'iot'
	option dest 'wan'

Also of course in /etc/config/network, create the IoT network with a static IP that does not overlap anything else in your network. In /etc/config/dhcp, set up a DHCP server for the IoT.