Bridged OPENVPN help

jmarcos.cano

hello i have set up my bridge openvpn server.
here some things i have to say before asking:

[*] my server is ubuntu 12.4
[*]my server is also my gateway/proxy/firewall/dhcp server/
[*]it has iptables setup already
[*]it also has a squid3 running

after that said

im having some difficulties setting the necessary iptables for this to work.. so long i have the eth0 (inside iface with 192.168.0.1/24 address) and also a br0 iface with 192.168.0.3/24 address. i've set this with the bridge-start & bridge-stop scripts provided with the howto.

the iptables statements i have to add to the existing script where:

-A INPUT -i tap0 -j ACCEPT

-A INPUT -i br0 -j ACCEPT

-A INPUT -p udp --dport 1194 -j ACCEPT

-A OUTPUT -o tap0 -j ACCEPT
-A OUTPUT -o br0 -j ACCEPT

my problem is that any hostname can reach the outside world (because they pass through the proxy/gateway)

but there are some hosts (static ip addresses) that can not reach the outside world, they have some privileges in the iptables script like:
-A FORWARD -i $INTIF -o $EXTIF --src 192.168.0.98 -j ACCEPT

any help will be appreciated.

are there any problems in where i APPEND the INPUT and OUTPUT new statements for the openvpn

jmarcos.cano

to clarify in my script i have

#some INPUT rules
#then:
-A INPUT -i tap0 -j ACCEPT
-A INPUT -i br0 -j ACCEPT
-A INPUT -p udp --dport 1194 -j ACCEPT
# Catch-all rule, reject anything else
-A INPUT -s $UNIVERSE -d $UNIVERSE -j REJECT

#all the OUTPUT rules
#then:
#for OPENVPN tap0 br0
-A OUTPUT -o tap0 -j ACCEPT
-A OUTPUT -o br0 -j ACCEPT
#last:
# Catch all rule, all other outgoing is denied and logged.
-A OUTPUT -s $UNIVERSE -d $UNIVERSE -j REJECT

#FORWARD chain rules
#this is where the hosts have a special set up, to permit them to bypass the proxy
#and last

-A FORWARD -j REJECT

COMMIT

brendan

first, find and install the fwBuilder app on a client PC. use it to build the ipTables policy and then "install" the policy on your gateway device. i cannot tell you how good of a job fwBuilder does with policies. i use it, and love it. i recommend it everywhere that people have issues with firewall policies.

in the policy you create, turn on logging and make sure it includes the rule numbers in the logs. when you know access that should be allowed has been denied for one of the machines with the static IP, you can then search the logs and find the rule that denied the access. modify that rule so that it allows the access you want the rule to allow.

as a matter of basic admin, your ipTables policy should always end in and "Any, Any, Any Deny" rule that blocks all attempts for access that fall through the policy and get to the last rule. this is what is considered a Default Deny or Fail Closed policy, and should be standard practice on all firewall policies. maybe you have this and are hitting it because no other rule in your policy is allowing the access? again, having logging turned on with rule numbers in the logs, will go a long way to help you determine the issue.

i am not clear about the decisions you made around eth0 and br0. are eth0 and tap0 bridged together?

if so, why do you have an IP on eth0 and on br0? only one (br0) needs an IP. if eth0 has an IP, br0 will use that IP. no need for both to have an IP.

if they are not bridged together, why wouldnt they be? could the eth0 interface be a source of issue because your iptables policy does not properly handle the traffic?

jmarcos.cano

i will try the logging option.. thanks..

br0 and eth0 are indeed bridged, the reason i choose that br0 and eth0 have a different address, is because the eth0 (ip address) is also the gateway in my LAN, and there are more than one script that use the variable eth0 to do some things, (so i dont want to interfer) also i dont want the br0 to be the gateway also... i just want it to be another "host" in my LAN..

i dont know if that made sense?

thank you for your time

brendan

eth0 cannot have its own IP when bridged. the IP, and therefore all traffic, must go to the br0 interface. this forces your bridged interface to have to be your LAN gateway address. this will not cause any impact to your traffic or cause your network to perform worse, etc.

as for your scripts:

cat <script_name> |sed -e 's/eth0/br0/g' > <new_script_name>

should get you most of the way done with that effort. you should not make a script's contents or references to a specific interface the reason you maintain broken configurations.

jmarcos.cano

thank you very much...