Can Using RPi B+ with OpenWRT somehow do away with having to set proxy settings on the devices in the network, and another issue with the local website on intranet

I am NewBee to OpenWRT and this level of network configuration.


This is my organisation Network.

From my office (the Network here) I connect to internet by configuring the proxy settings (no username or password) on each of the devices I use.
The Wifi Router is my personal and in my office.

My querues

  1. Is it possible to configure OpenWRT on a raspberry Pi Model B+ using only ethernet ports - one RPi port and another USB to Ethernet port - so that proxy is resolved on the RPi and internet is supplied to all the devices in the Network without doing any proxy configuration in them.

  2. If I insert the RPi with OpenWRT between Wifi Router and the network, I am not able to access the institute website (which is in the intranet - not accessible from internet), while I can get access to internet.

The OpenWRT configuration files - (i am not using wifi)

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

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

config globals 'globals'
	option ula_prefix 'fd55:e1b6:bf5e::/48'

config device
	option name 'br-lan'
	option type 'bridge'
	option mtu '1500'
	option txqueuelen '1000'
	option macaddr 'B8:27:EB:8B:2C:DC'
	list ports 'eth0'
	list ports 'eth1'

config interface 'lan'
	option proto 'static'
	option device 'eth1'
	option ipaddr '192.168.0.1'
	option netmask '255.255.0.0'

config interface 'wan'
	option proto 'dhcp'
	option device 'eth0'
root@OpenWrt:~# cat /etc/config/dhcp

config dnsmasq
	option domainneeded '1'
	option boguspriv '1'
	option filterwin2k '0'
	option localise_queries '1'
	option rebind_protection '1'
	option rebind_localhost '1'
	option local '/lan/'
	option domain 'lan'
	option expandhosts '1'
	option nonegcache '0'
	option authoritative '1'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
	option nonwildcard '1'
	option localservice '1'
	option ednspacket_max '1232'

config odhcpd 'odhcpd'
	option maindhcp '0'
	option leasefile '/tmp/hosts/odhcpd'
	option leasetrigger '/usr/sbin/odhcpd-update'
	option loglevel '4'

config dhcp 'eth1'
	option interface 'eth1'
	option start '100'
	option limit '150'
	option leasetime '12h'

config dhcp 'eth0'
	option interface 'eth0'

config dhcp 'lan'
	option start '100'
	option leasetime '12h'
	option limit '150'
	option interface 'lan'

root@OpenWrt:~# cat /etc/config/firewall

config defaults
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option synflood_protect '1'

config zone
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	option masq '1'
	list network 'lan'

config zone
	option name 'wan'
	option output 'ACCEPT'
	option masq '1'
	list network 'wan'
	option input 'REJECT'
	option forward 'REJECT'

config forwarding
	option dest 'lan'

config forwarding
	option src 'lan'
	option dest 'wan'

15 years ago, yes - today, no.

HTTPS makes transparent proxying impossible (unless you can install your proxy certificate on each client, but in that case you could rather configure the proxy instead). HTTP and HSTS both encrypts and authenticates the data, preventing interception or filtering - while you can still use proxies, but only configured explicitly and only in CONNECT mode (without caching or interception).

1 Like

Thanks. I understand from your explanation that it is better to configure proxy on the clients.

Any thoughts on this problem.

Have a look at:

Thanks one of these these should prevent the effort in configuring proxy in the clients.
I was just wondering whether it can be entirely avoided. I understand now that perhaps that is not possible.

I remember once I set up a proxy server on my office computer using proxify (just for my curious mind) over a VPN (hamachi) (hope I anm anble to explain what I did) and was able to access the network over internet. But again another proxy was involved

What exactly do you want to avoid?

Unfortunately not:

  • PAC is mainly useful for split routing, but it requires manual configuration.
  • WPAD is disabled by default in all modern OS due to security reasons.

In my experience, even enabling WPAD doesn't solve the problem entirely since some apps ignore system-wide configuration and require explicit settings.

In short, proxy still requires client-side configuration, unless you are in a corporate network, where you can utilize AD GPO, Ansible roles, etc. to deploy the settings.

2 Likes

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.