1

I’m running OPENWRT chaos calmer on top of Raspberry pi 2. I successfully configured the OPENVPN client and client route my traffic through the VPN tunnel. But when I reboot the pi LAN interface connect directly to the WAN interface for small time and route traffic outside the VPN tunnel. This will only happen for very small time. (Time that need VPN client to start). But I need to stop this. I need to route almost all the traffic through VPN client all the time and if the VPN not connected user should not able to access the internet. I configured Proxy client called TINYPROXY with this setup and may be it will cause the problem. But I have not clear idea how to stop this

These are my configs

/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 interface 'lan'
    option ifname 'eth0'
    option proto 'static'
    option netmask '255.255.255.0'
    option ipaddr '192.168.2.1'
    option dns '8.8.8.8 8.8.4.4'

config interface 'wan'
    option ifname 'eth1'
    option proto 'dhcp'
    option peerdns '0'
    option dns '8.8.8.8 8.8.4.4'

config globals 'globals'
    option ula_prefix 'fd14:b495:5965::/48'

config interface 'vpn0'
    option ifname 'tun0'
    option proto 'none'
    option auto '1'
    option delegate '0'

/etc/config/firewall

config defaults
    option syn_flood '1'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'ACCEPT'

config zone
    option name 'lan'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'ACCEPT'
    option network 'lan'

config zone
    option name 'wan'
    option output 'ACCEPT'
    option masq '1'
    option mtu_fix '1'
    option input 'ACCEPT'
    option forward 'ACCEPT'
    option network 'wan wan6 vpn0'

config rule
    option name 'Allow-DHCP-Renew'
    option src 'wan'
    option proto 'udp'
    option dest_port '68'
    option target 'ACCEPT'
    option family 'ipv4'

config rule
    option name 'Allow-Ping'
    option src 'wan'
    option proto 'icmp'
    option icmp_type 'echo-request'
    option family 'ipv4'
    option target 'ACCEPT'

config rule
    option name 'Allow-IGMP'
    option src 'wan'
    option proto 'igmp'
    option family 'ipv4'
    option target 'ACCEPT'

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

config redirect
#   option target 'DNAT'
#   option dest 'vpn'
    option name 'Transparent Proxy Redirect'
    option src 'lan'
    option proto 'tcp'
    option dest_port '8888'
    option src_dport '80'
    option src_dip '!192.168.2.1'
    option dest_ip '192.168.2.1'

config zone
    option name 'vpn'
    option masq '1'
    option input 'ACCEPT'
    option forward 'ACCEPT'
    option output 'ACCEPT'
    option network 'vpn0'

config forwarding
    option src 'vpn'
    option dest 'lan'

/etc/config/tinyproxy

config tinyproxy
    option enabled '1'
    option User 'nobody'
    option Group 'nogroup'
    option Port '8888'
    option Timeout '600'
    option DefaultErrorFile '/usr/share/tinyproxy/default.html'
    option StatFile '/usr/share/tinyproxy/stats.html'
    option LogFile '/var/log/tinyproxy.log'
    option LogLevel 'Info'
    option MaxClients '100'
    option MinSpareServers '5'
    option MaxSpareServers '20'
    option StartServers '10'
    option MaxRequestsPerChild '0'
    option ViaProxyName 'tinyproxy'
    list Allow '127.0.0.1'
    list Allow '192.168.2.1/24'
    list ConnectPort '443'
    list ConnectPort '563'
    list ConnectPort '80'
    option Filter '/www/textui/tinyproxy/blocked.txt'

I want to exactly achieve this

USER --> LAN --> TINYPROXY --> VPN --> WAN

My TINYPROXY is working perfectly fine. All the other configs are working fine. The problem only exists for small time when PI reboot

Could someone help me in this?

|improve this question
  • What kind of traffic is getting out, before the OpenVPn is setup? Is that the DHCP traffic? – MariusMatutiae Oct 26 '15 at 15:56
  • Reset to default and do not change your rules to allow everything. Then set the firewall to forward only from LAN to VPN. – qasdfdsaq Oct 26 '15 at 16:00
  • @MariusMatutiae I check it using ping command. As soon as reboot few icmp packets go outside the tunnel (ping to google dns 8.8.8.8) – gripenfighter Oct 26 '15 at 16:37
  • @qasdfdsaq you mean reset pi to default factory settings ? I can do it but then I will need reconfigure each an every package again. Is there any easy way to fix this ? without resetting ? – gripenfighter Oct 26 '15 at 16:39
  • No I mean reset Openwrt's firewall to default. – qasdfdsaq Oct 26 '15 at 16:41
0

This is (for me!) a difficult question. I can offer a partial solution, and an idea to test for a full solution.

IF this were a regular Linux, like for instance a Debian, one could insert, in the file /etc/network/interfaces, in the stanza for the outer interface (let's call it wan), the following line:

  pre-up iptables -A OUTPUT -s 192.168.0.0/24 -o wan -j DROP

where I assumed that your LAN is 192.168.0.0/24. The fact that we use pre-up makes it a certainty that the firewall rule is in effect when the wan interface is brought up. Together with the rule:

 iptables -t nat -A POSTROUTING -o wan -j MASQUERADE

we could be sure that packets from LAN only pass thru tun0, even though some would be dropped as we wait for OpenVPN to establish the connection to its server.

However, I have been unable to find in the Web Pages of OpenWRT a substitute for the pre-up condition above. So, if you setup your firewall with the two rules above, you will be certain that no packet from your LAN leaves your router outside the OpenVPN, but you are not sure that the iptables firewall will be up before networking.

In this OpenWRT Wiki page, the order of execution of different services is explained:

rcS executes the symlinks to the actual startup scripts located in /etc/rc.d/S##xxxxxx with option "start":

.....

S40network start a network subsystem (run /sbin/netifd, up interfaces and wifi

S45firewall create and implement firewall rules from /etc/config/firewall

You see that the two services are started one after the other, which leaves little time for packets to pass; this is surely better than waiting for the OpenVPN to come up. This is my partial solution: it is partial because I have shortened the time during which LAN packets can pass, but I have not made this time .=0

You may try inverting the two services, i.e. renaming them: 

      S40firewall
      S45network

and see whether this works. I am not sure about what iptables/netfilter does, when the interface it tries to protect does not even exist. On my Debian this worked fine but, since I do not have an OpenWRT to try this on, I cannot be positive this will work for you too. This is my suggestion for a full solution. Cheers.

|improve this answer
  • Thanks for the complete answer. I'll try this and let you know. Netfilter use iptables to do the things but if I going to change Iptables directly what happened the rules configured by netfilter ? I use openwrt chaos calmer on vbox for testing. dropbox.com/s/gvefvvjm88hs3zp/… – gripenfighter Oct 27 '15 at 7:25
  • @charith iptables is the USERland side of netfilter. – MariusMatutiae Oct 27 '15 at 7:26
0

The problem is that your packets aren't coming from the lan, they're coming from the router which is running your proxy. There's no rule in the firewall to force outgoing traffic through the VPN on the router.

I haven't tried this, but...

Set option output REJECT in your wan interface, then add specific rules to permit outgoing traffic on the wan interface to the servers and ports that the router needs (dhcp, OpenVPN) prior to the vpn coming up. In these rules, you'll have option output ALLOW and option dest wan but don't set src.

Alternatively, keep allowing outgoing traffic on the zone, and create rules that block HTTP traffic to the wan. Again, don't set src.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.