Win - Mac - BSD Block traffic when VPN disconnects

[jessez 3]

Hi dmd,

I'm not totally sure what you mean by this:

am i correct in assuming that this will work with 10.6.8, since it uses ipfw and not pf?

These rules/script is not for pf; it won't work.

but if you want the script working on a network with 10.6.8.xxx address space, and also only connects to Castor, change this line:

sudo ipfw add 02000 allow ip from 172.17.0.0/16 to 108.59.8.147 keep-state

to:

sudo ipfw add 02000 allow ip from 10.6.8.0/24 to 95.211.169.3 keep-state

"how would i go about only using these rules for en0 "

Add "on en0" on rules 1600, 1800 and 2000 after "allow ip" like this (you could also change "ip" to tcp or udp if you only want to connect using one or the other - the script was meant to be useful in the most number of cases without protocol issues. Also I have found for the tun0 connection using ip works the best, so leave those ones as is.):

sudo ipfw add 02000 allow ip on en0 from 10.6.8.0/24 to 95.211.169.3 keep-state

you don't want to do the other rules because they're for lo ( rule 1000), and for tun0 (rules 5000 and 5200)

" my private ip space (all electronics in my network) is 10.0.0.0/16; would i even need "sudo ipfw add 02000 allow ip from <strong>172.17.0.0/16</strong> to 108.59.8.147 keep-state"?"

That is the rule that connects you to the VPN server, so yes, and modified as above to reflect using Castor instead of Sirius and your address space instead of 172.17.x.x space.

"//EDIT:

basically, i want to deny every outgoing connection that is not going through tun0 (95.211.169.3 -- castor). internal network access should be allowed though; the ip address space is 10.0.1.0-10.0.1.200."

I'm going to have to check into the subnet masking for this one, as AirVPN is also using 10.x.x.x address space. If your home network was using 172.x.x.x or 192.x.x.x, it would be easy, but you don't want your external and internal traffic interfering with each other. Otherwise, the rules as they are will tunnel everything through tun0.

You can confirm that by running the script and trying to connect with any software to anyplace on the internet when you are connected to something other than AirVPN (ie. just your router,etc) , and the Castor server. If you can get web access or email, etc, while not connected to Castor, then there is a problem. If you only get access when connected to Castor, it is working as intended.

I hope that helps, and I'll do some number crunching later with the subnets and see if I can come up with a local network rule for you.

jz

[dmd 0]

thank you. sorry for not expressing myself clearer; with 10.6.8 i meant my os x version

since my internal address space is 10.0.1.0-10.0.1.200, wouldn't that be expressed as 10.0.1.0/24 and thus be different (enough) from AirVPN's 10.0.0.0/16 address space?

[jessez 3]

Hi dmd,

Sorry it took a while to get back to you, I've been very busy.

"with 10.6.8 i meant my os x version"

oops, that didn't even occur to me.

"wouldn't that be expressed as 10.0.1.0/24 and thus be different (enough) from AirVPN's 10.0.0.0/16 "

I don't think so, but I'm having a difficult time figuring that out, I'm much more familiar with the old way of expressing subnets, although even that can be tricky for me.

Admins: could you help with this one? I don't want to miss-guide dmd, and create a mess of redirected traffic. Thanks guys!

dnd: if you get no reply from the admins on this in the next couple of days, maybe start a new topic or contact them directly for help on it.

Sorry I couldn't be more help,

jz

[dmd 0]

thanks, you taking the time to write such elaborate answers is much appreciated. assuming i go through the trouble of changing my internal address space to say... 10.6.8.xxx , would the following be correct? only want it to work while on en0...

sudo sysctl -w net.inet.ip.fw.enable=0
sudo sysctl -w net.inet.ip.forwarding=0
sudo ipfw flush
sudo ipfw delete set 31
sudo /sbin/ipfw disable firewall
sudo /sbin/ipfw enable firewall
sudo sysctl -w net.inet.ip.fw.enable=1
sudo ipfw add 01000 allow ip from any to any via lo*
sudo ipfw add 01200 deny ip from any to 127.0.0.0/8
sudo ipfw add 01400 check-state
sudo ipfw add 01600 allow ip on en0 from any 67 to any 68 in
sudo ipfw add 01800 allow ip on en0 from any 5353 to any in
sudo ipfw add 02000 allow ip on en0 from 10.6.8.0/24 to 95.211.169.3 keep-state
sudo ipfw add 04000 allow ip from 127.0.0.1 to any
sudo ipfw add 05000 allow ip from 10.0.0.0/8 to any
sudo ipfw add 05200 allow ip from any to 10.0.0.0/8
sudo ipfw add 65534 deny log ip from any to any
sudo ipfw add 65535 allow ip from any to any

to be honest, i am still slightly confused about rule 05000 and 05200. where does the 10.0.0.0/8 come from? are those for airvpn? what does rule 01600 do?

[Staff 9973]

Hi dmd,

I don't think so, but I'm having a difficult time figuring that out, I'm much more familiar with the old way of expressing subnets, although even that can be tricky for me.

[...]

dnd: if you get no reply from the admins on this in the next couple of days, maybe start a new topic or contact them directly for help on it.

Sorry I couldn't be more help,

jz

Hello!

The address range 10.0.0.0/16 (10.0.0.0->10.0.255.255) will not conflict with VPN IP addresses (10.4.0.0->10.9.255.255).

However, the rule pertaining to 10.0.0.0/8 needs to be modified accordingly for clients that use as their internal network the address range 10.0.0.0/16 (or even 10.0.0.0/24), because 10.0.0.0/8 covers the range 10.0.0.0->10.255.255.255.

In CIDR notation, the range 10.4.0.0->10.9.255.255 may be represented with the following:

10.4.0.0/16

10.5.0.0/16

10.6.0.0/16

10.7.0.0/16

10.8.0.0/16

10.9.0.0/16

A CIDR Notation Calculator may help you, for example:

http://www.subnet-calculator.com/cidr.php

Kind regards

[galilao 2]

Hello,

A local restaurant has wireless service with an IP address of 10.1.10.95 and router address of 10.1.10.1.

I changed the 172.17.x.x line to 10.1.10.1/8 and found that it does not block when the VPN is disconnected.

I also tried 10.1.10.95/8 with the same results, no blocking when the VPN is disconnected?

What is wrong?

Below is the program:

sudo sysctl -w net.inet.ip.fw.enable=0

sudo sysctl -w net.inet.ip.forwarding=0

sudo ipfw flush

sudo ipfw delete set 31

sudo /sbin/ipfw disable firewall

sudo /sbin/ipfw enable firewall

sudo sysctl -w net.inet.ip.fw.enable=1

sudo ipfw add 01000 allow ip from any to any via lo*

sudo ipfw add 01200 deny ip from any to 127.0.0.0/8

sudo ipfw add 01400 check-state

sudo ipfw add 01600 allow ip from any 67 to any 68 in

sudo ipfw add 01800 allow ip from any 5353 to any in

sudo ipfw add 02000 allow ip from 10.1.10.1 to 108.59.8.147 keep-state

sudo ipfw add 04000 allow ip from 127.0.0.1 to any

sudo ipfw add 05000 allow ip from 10.0.0.0/8 to any

sudo ipfw add 05200 allow ip from any to 10.0.0.0/8

sudo ipfw add 65534 deny log ip from any to any

sudo ipfw add 65535 allow ip from any to any

Thank you

[jessez 3]

Hi galilao,

Ok, so the problem is that these two lines need to be changed also for the restaurant, and maybe better just to change them to the actual subnet for AirVPN:

sudo ipfw add 05000 allow ip from 10.0.0.0/8 to any

sudo ipfw add 05200 allow ip from any to 10.0.0.0/8

These IPs with the /8 encompasses the whole 10.x.x.x IP range, so that would include the restaurants router IP.

So, the fix would be like this:

sudo ipfw add 02000 allow ip from 10.1.10.1/24 to 108.59.8.147 keep-state (restaurant range minimal; 10.1.10.0 through 10.1.10.255), to Sirius server IP)

AND:

[NOTE: these for TCP connections]

sudo ipfw add 05000 allow ip from 10.5.0.0/16 to any

sudo ipfw add 05200 allow ip from any to 10.5.0.0/16

The other thing I just discovered is it looks like Vega and Sirius both use a different range for a TCP connection vs a UDP connection (I didn't check the EU servers, just the US ones, so they may all be like that).

So TCP is running in the 10.5.0.0 range and UDP is running in the 10.4.0.0 range.

So the 5000 rule and 5200 rule would be this instead, if using UDP:

sudo ipfw add 05000 allow ip from 10.4.0.0/16 to any

sudo ipfw add 05200 allow ip from any to 10.4.0.0/16

I think that should resolve the issue, let me know if not.

Regards,

jz

[jessez 3]

Hi admins,

Many many thanks for the link to the CIDR calculator, that'll help me avoid all kinds of tricky math!! I can't believe I never found one of those before... oh well maybe it was helping my old brain stay active anyway!

Thanks again and best regards,

jz

[jessez 3]

hi dmd,

"to be honest, i am still slightly confused about rule 05000 and 05200. where does the 10.0.0.0/8 come from? are those for airvpn? what does rule 01600 do?"

OK, 5000 and 5200 are the VPN link, they are the ones that allow the traffic to tunnel from you to the VPN server.

rule: 05000 allow ip from 10.0.0.0/8 to any

ip = allow any protocol (TCP, UDP, ICMP, etc..) - this avoids having multiple rules just to allow the necessary protocols the connection needs.

from = the ip address range from which an IP address will be assigned to your tun connection from the AirVPN server.

10.0.0.0/8 is the entire 10.x.x.x address range as described by the admins a couple or three posts ago.

to any = to any IP address, but as it is a tunneled connection it will only go to an AirVPN server.

rule: 05200 is pretty much the same thing but allowing the traffic back from AirVPN server to you.

rule 01600 : allow ip from any 67 to any 68 in

Again ip being any protocol, although that could probably be changed to dhcp and still work as the 67 to any 68 are the dhcp send and recieve ports. If you only ever use static ip addresses, you could delete that rule and still be ok. This rule shouldn't be neccessary for getting the DHCP address from AirVPN.

rule 01800 : refers to port 5353 for mDNS and DNS - for some reason Apple adopted mDNS from Microsoft in either SnowLeopard or Lion, I don't remember which right now, so you probably need that one for local connections like bonjour and airplay if you are using either of those.

If you're into a little light (lol) reading, you could study man ipfw, which has way too much information, but by reading and looking at your ruleset, it will become a lot more clear how and what all the rules are doing. If your planning on switching to 10.7 or 10.8 you might want to study the pf firewall instead, as that the default in the two newer Os/s.

I hope that helps some.

Regards,

jz

[Staff 9973]

The other thing I just discovered is it looks like Vega and Sirius both use a different range for a TCP connection vs a UDP connection (I didn't check the EU servers, just the US ones, so they may all be like that).

Hello!

All the servers use and push the same VPN IP addresses according to the port you connect to. Please see here:

https://airvpn.org/specs

Kind regards

[dmd 0]

thanks admin and jessez. so would the following be the correct set of rules for my setup (castor, en0 only, internal ip addresses 10.0.1.xxx)?

sudo sysctl -w net.inet.ip.fw.enable=0
sudo sysctl -w net.inet.ip.forwarding=0
sudo ipfw flush
sudo ipfw delete set 31
sudo /sbin/ipfw disable firewall
sudo /sbin/ipfw enable firewall
sudo sysctl -w net.inet.ip.fw.enable=1
sudo ipfw add 01000 allow ip from any to any via lo*
sudo ipfw add 01200 deny ip from any to 127.0.0.0/8
sudo ipfw add 01400 check-state
sudo ipfw add 01600 allow ip on en0 from any 67 to any 68 in
sudo ipfw add 01800 allow ip on en0 from any 5353 to any in
sudo ipfw add 02000 allow ip on en0 from 10.0.0.0/16 to 95.211.169.3 keep-state
sudo ipfw add 04000 allow ip from 127.0.0.1 to any
sudo ipfw add 05100 allow ip from 10.4.0.0/16 to any
sudo ipfw add 05110 allow ip from 10.5.0.0/16 to any
sudo ipfw add 05120 allow ip from 10.6.0.0/16 to any
sudo ipfw add 05130 allow ip from 10.7.0.0/16 to any
sudo ipfw add 05140 allow ip from 10.8.0.0/16 to any
sudo ipfw add 05150 allow ip from 10.9.0.0/16 to any
sudo ipfw add 05210 allow ip from any to 10.4.0.0/16
sudo ipfw add 05220 allow ip from any to 10.5.0.0/16
sudo ipfw add 05230 allow ip from any to 10.6.0.0/16
sudo ipfw add 05240 allow ip from any to 10.7.0.0/16
sudo ipfw add 05250 allow ip from any to 10.8.0.0/16
sudo ipfw add 05260 allow ip from any to 10.9.0.0/16
sudo ipfw add 65534 deny log ip from any to any
sudo ipfw add 65535 allow ip from any to any

[Staff 9973]

Hello!

In your case, in order to have a cleaner, more precise set of rules, rule 2000 should be changed to:

allow ip on en0 from 10.0.1.0/24 to 95.211.169.3 keep-state

because 10.0.1.* in CIDR notation is 10.0.1.0/24

Rules from 5100 to 5260 can be made cleaner with "on tun0" (assuming that tun0 is your tun interface), for example:

allow ip on tun0 from 10.4.0.0/16 to any

Pay attention to rule 1200 if you wish to use a local proxy (for example Air over proxy will be blocked with that rule if you have a proxy on 127.0.01) and/or if you have software which needs to communicate with 127.0.0.1 (for example Tunnelblick).

Kind regards

[dmd 0]

i am using viscosity; would that work? can't i just comment that rule out?

\\EDIT:

so. i added all the rules, got a kernel panic immediately after, restarted, all rules were gone

[galilao 2]

Hello Admin, What is the meaning of the phrase "push the same VPN IP addresses..."? Thank you

[galilao 2]

Hello jz,

I went back to the restaurant and your modifications worked.

What did I need to know in order to realize that 10.0.0.0/8 needed to be changed to 10.4.0.0/16?

As I go from place to place, the router addresses are going to be different from 192.168.x.x or 172.17.x.x or 10.1.x.x, so I am hoping to be able to figure out the proper modifications.

Thank you

[galilao 2]

Hello jz,

I forgot to ask what modifications would I have to make to the restaurant program to make it work with 10.7 Lion?

Thank you

[jessez 3]

hi galilao,

Just for clarity, for other forum visitors, what you are referring to as a "program" is actually a script.

"what modifications would I have to make to the restaurant program to make it work with 10.7 Lion?"

Well, the answer is none, but with the proviso that you're going to keep using ipfw.

Ipfw is depreciated in Lion, but ipfw is still there and works the same, so you can still keep using it.

If you want to use the pf firewall (the default in Lion), the latest rules I created are posted in this article:

https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=2935&Itemid=142

There are lots of posts in this article about pf as well, with lots of useful information for you.

You'll need to change the appropriate IP addresses in the rules, as you have been doing in ipfw. The downside to this is that all the info is stored in /etc/pf.conf , so you'll need to change the permissions there to allow you to modify the file. Also if you are going to be changing locations a lot, you'll want to make scripts to provide you the easy setup when changing locations. man pfctl is the place where there's lots of good info.

Also good articles here:

http://undeadly.org/cgi?action=article&sid=20060929080943

http://www.probsd.net/pf/index.php/PF_Flow_Diagram

http://www.openbsd.org/faq/pf/filter.html

I hope that helps,

Regards,

jz

[jessez 3]

Hi again galilao, sorry I missed this question to put the answer in the last post.

"What did I need to know in order to realize that 10.0.0.0/8 needed to be changed to 10.4.0.0/16?"

Most of the time, I think you'll be ok just using a /16 for anywhere you are, but if that doesn't work then this is what you can do to find out for sure:

First find out the routers IP address of the network you want to connect to.

Then use the calculator that the admins suggested here: http://www.subnet-calculator.com/cidr.php

Put the router IP address in the "IP address" box. (I've found when using this tool, it's better to backspace out the O's that are there, as they tend to pop back.)

Then use the "Mask Bits" dropdown to change the range that it shows in the "CIDR Address Range" field. What you want to accomplish there is that your DHCP assigned address is in the range shown, and as little extra as possible. Anytime you use a /16 for Mask Bits, it's going to give you the standard range that a basic router covers. However you may need to prune the range down to exclude some conflict in the network.

ie: For a router with an address of 192.168.0.1, you can put that in the tool with 16 as the mask bits and get this range: 192.168.0.0 to 192.168.255.255.

By changing the Mask Bits up to /24 which will give you the range 192.168.0.0 - 192.168.0.255 which is a smaller range.

To be honest I can only think of two scenarios where this kind of range pruning might be neccessary. One would be as dnd needed because his home network is in the 10.x.x.x range which the tun adapter get for the VPN connection, and the other being where the local range is a bit oddball like your school environment and corporate networks.

Then at the extreme end, using the same example, you get only the routers 192.168.0.1 address, by using a mask bit of /32. There are mask bits all the way from 1 - 32, so they giveyou a very wide variety of "inclusive" or exclusive addresses. For example, if you know a given netowrk is only assigning IP's in the 192.168.0.2 - 192.168.0.15 range, you could use a Mask Bit of 28 and still get connected.

Anyway, thats a brief summary of how subnets using CIDR works,

Regards,

jz

[jessez 3]

Hi dnd,

" i am using viscosity; would that work? can't i just comment that rule out?"

I am using Viscosity now, and so I did a packet capture to find the answer, which is no. I'm not sure if Viscosity or OpenVPN is routing packets through 127.0.0.1, but there definitely is VPN traffic on that IP address. There are many other softwares that use it also, so it's best (and perfectly safe) to let your machine use it.

\\EDIT:

so. i added all the rules, got a kernel panic immediately after, restarted, all rules were gone

Did you run it as a script or add the rules manually?

There isn't anything in there that should cause a panic, but if you're still having a problem; copy and paste each line separately out of the script into terminal and see which line is causing it.

Regards,

jz

[dmd 0]

fairly positive it was the "deny all" rule at the end that killed my system...

[galilao 2]

Hello, Thanks for your help. I am trying to create a script to run from an airplane airport terminal lobby, not to be confused with an Apple Airport transmitters.

The IPv4 address is 10.252.53.167

The subnet mask is 255.255.255.0

The router address is 10.252.53.254

I wrote the following script after consulting the CIDR website:

net.inet.ip.fw.enable: 1 -> 0

net.inet.ip.forwarding: 0 -> 0

Are you sure? [yn] y

Flushed all rules.

net.inet.ip.fw.enable: 0 -> 1

net.inet.ip.forwarding: 0 -> 0

02000 allow ip from 10.252.0.0/24 to 46.165.208.65 keep-state

02004 allow ip from 10.252.0.0/24 to 95.211.169.3 keep-state

02008 allow ip from 10.252.0.0/24 to 178.248.29.132 keep-state

02012 allow ip from 10.252.0.0/24 to 108.59.8.147 keep-state

02016 allow ip from 10.252.0.0/24 to 69.163.36.66 keep-state

02020 allow ip from 10.252.0.0/24 to 89.149.226.185 keep-state

02024 allow ip from 10.252.0.0/24 to 146.185.25.170 keep-state

02028 allow ip from 10.252.0.0/24 to 62.212.85.65 keep-state

02032 allow ip from 10.252.0.0/24 to 85.17.123.26 keep-state

02036 allow ip from 10.252.0.0/24 to 95.211.98.154 keep-state

04000 allow ip from 127.0.0.1 to any

05000 allow log ip from 10.0.0.0/24 to any

05200 allow log ip from any to 10.0.0.0/24

05000 allow log ip from 10.0.0.0/24 to any

05200 allow log ip from any to 10.0.0.0/24

I can connect to AirVPN, but the browser cannot connect to the Internet. What is wrong?

I notice that my computer also wants to connect to UDP port 67 to 172.24.240.178.

Hope to hear from you.

[Guest ergolon]

Hi there,

refering to https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=1713&limit=6&limitstart=36&Itemid=142#2532, how do I enable portforwarding to my machine in pf.conf?

Probably this has already been answered, but I just couldn´t find it via search...

Thanks for your help!

ergolon

[Staff 9973]

Hi there,

refering to https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=1713&limit=6&limitstart=36&Itemid=142#2532, how do I enable portforwarding to my machine in pf.conf?

Probably this has already been answered, but I just couldn´t find it via search...

Thanks for your help!

ergolon

Hello!

You don't need any "allow" rule on pf (as long as there are no blocking rules for ports on your tun interface): all the traffic is tunneled to/from a single port so all the packets will be properly forwarded to the correct application without need of pf policy. Just make sure that you have remotely forwarded the port(s) you wish on our system.

https://airvpn.org/faq

Kind regards

[Guest ergolon]

Hello admin,

thanks for your kind reply.

That doesnt seem to work. I tried this:

I´m connected through my DD-WRT router to the internet.

First, I connect to Castor (UDP/443) with my Mac.

Then I use IceFloor to disable PF ("Disable PF firewall and uninstall boot scripts").

Then I checked results from http://www.canyouseeme.org:

Success: I can see your service on 95.211.169.45 on port (XXXXX)

Your ISP is not blocking port 50503

hen I use IceFloor to enisable PF ("Enable PF firewall and install boot scripts").

Checked again results from http://www.canyouseeme.org:

Error: I could not see your service on 95.211.169.45 on port (XXXXX)

Reason: Connection refused

When I disable PF, canyouseeme.org is able to see me again on the selected port.

Any ideas?

Thanks a lot,

Ergolon

[Guest ergolon]

One more question: In the FAQ, it says: "IMPORTANT: do NOT forward on your router the same ports you use on your listening services while connected to the VPN. Doing so exposes your system to correlation attacks and potentially causes uncencrypted packets to be sent outside the tunnel from your client."

What does this mean?

Right now, I´m connected to the internet via router. On the Router (DD-WRT) I´m forwarding port ranges (XXX01-XXX05) internally to 192.168.0.2 (that´s my Mac). This is exactly the same port range that I´m forwarding through the members area via AirVPN so all ports get forwarded from the server through AirVPN through my router to my Mac...

Hope that´s ok?

Thanks,

Ergolon