VPN Through Firewall To Office

>From home, I use vpnc on Ubuntu 5.04 to get to my office VPN which is
the typical Cisco variety on IPSEC and RSA SecurID. I currently have my
workstation behind another NAT router/firewall.

If I put myself with no local firewall, I get through just fine on VPN
and a ShieldsUp check shows that I've got no open ports. So that's all
well and fine.

However, if I improve things a bit and put myself through an
INPUT-based, limited, local firewall like:

Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT udp -- mydns1.net anywhere udp spt:domain
ACCEPT udp -- mydns2.net anywhere udp spt:domain
REJECT tcp -- anywhere anywhere tcp
flags:SYN,RST,ACK/SYN reject-with icmp-port-unreachable
REJECT udp -- anywhere anywhere udp
reject-with icmp-port-unreachable

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination



....I find I cannot VPN through this -- vpnc just hangs and times out,
waiting for a response back.

What do I need to do with iptables to poke my VPN connection through?

Also, I think I heard that ipsec uses port 500. Do I just need to
expose that?

googlemike@hotpop.com wrote:
> The following local firewall won't permit me to VPN...
>
> Chain INPUT (policy ACCEPT)
> target prot opt source destination
> ACCEPT all -- anywhere anywhere
> ACCEPT udp -- mydns1.net anywhere udp spt:domain
> ACCEPT udp -- mydns2.net anywhere udp spt:domain
> REJECT tcp -- anywhere anywhere tcp
> flags:SYN,RST,ACK/SYN reject-with icmp-port-unreachable
> REJECT udp -- anywhere anywhere udp
> reject-with icmp-port-unreachable
>
> Chain FORWARD (policy ACCEPT)
> target prot opt source destination
>
> Chain OUTPUT (policy ACCEPT)
> target prot opt source destination
>
> What do I need to do with iptables to poke my VPN connection through?
>

Nevermind, I figured it out by using "netstat -a -p | grep vpnc", which
said something about "udp isakmp" and some testing with tcp and udp
port permissions on that result. The key 2 lines are set off with an
asterisk. (Remove those if you use this in your situation.)

Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
* ACCEPT tcp -- anywhere anywhere tcp
dpt:isakmp flags:SYN,RST,ACK/SYN
* ACCEPT udp -- anywhere anywhere udp
dpt:isakmp
ACCEPT udp -- nsatla01.verizon.net anywhere udp
spt:domain
ACCEPT udp -- nsdall01.verizon.net anywhere udp
spt:domain
REJECT tcp -- anywhere anywhere tcp
flags:SYN,RST,ACK/SYN reject-with icmp-port-unreachable
REJECT udp -- anywhere anywhere udp
reject-with icmp-port-unreachable

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

---

To achieve those lines, I did:

iptables -A INPUT -p tcp -m tcp --dport 500 --syn -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 500 -j ACCEPT

....prior to the iptables commands to set my DNS query permissions.

googlemike@hotpop.com wrote:
> googlemike@hotpop.com wrote:
>> The following local firewall won't permit me to VPN...
<snip>
>> What do I need to do with iptables to poke my VPN connection through?

<snip: works now, using...>
> iptables -A INPUT -p tcp -m tcp --dport 500 --syn -j ACCEPT
> iptables -A INPUT -p udp -m udp --dport 500 -j ACCEPT

TCP is not required. IPSec often uses isakmp for key negotiation; this
means port 500/udp. If you are using NAT-Traversal, you'll also require
4500/udp. You'll know if you're using NAT-T by the number of headaches
setup caused you... ;-)

Joachim

googlemike@hotpop.com wrote in news:1122173785.227534.107190
@g47g2000cwa.googlegroups.com:

>>From home, I use vpnc on Ubuntu 5.04 to get to my office VPN which is
> the typical Cisco variety on IPSEC and RSA SecurID. I currently have my
> workstation behind another NAT router/firewall.
>
> If I put myself with no local firewall, I get through just fine on VPN
> and a ShieldsUp check shows that I've got no open ports. So that's all
> well and fine.
>
> However, if I improve things a bit and put myself through an
> INPUT-based, limited, local firewall like:
>
> Chain INPUT (policy ACCEPT)
> target prot opt source destination
> ACCEPT all -- anywhere anywhere
> ACCEPT udp -- mydns1.net anywhere udp spt:domain
> ACCEPT udp -- mydns2.net anywhere udp spt:domain
> REJECT tcp -- anywhere anywhere tcp
> flags:SYN,RST,ACK/SYN reject-with icmp-port-unreachable
> REJECT udp -- anywhere anywhere udp
> reject-with icmp-port-unreachable
>
> Chain FORWARD (policy ACCEPT)
> target prot opt source destination
>
> Chain OUTPUT (policy ACCEPT)
> target prot opt source destination
>
>
>
> ...I find I cannot VPN through this -- vpnc just hangs and times out,
> waiting for a response back.
>
> What do I need to do with iptables to poke my VPN connection through?
>
> Also, I think I heard that ipsec uses port 500. Do I just need to
> expose that?
>

Udp port 500 is used for isakmp in association with esp (encapsulated
security protocol). Esp is protocol 50 (tcp is protocol 6). If your vpn is
using esp, you will have to allow that protocol as well as udp port 500.

Klazmon.

googlemike@hotpop.com wrote in news:1122173785.227534.107190
@g47g2000cwa.googlegroups.com:

>>From home, I use vpnc on Ubuntu 5.04 to get to my office VPN which is
> the typical Cisco variety on IPSEC and RSA SecurID. I currently have my
> workstation behind another NAT router/firewall.
>
> If I put myself with no local firewall, I get through just fine on VPN
> and a ShieldsUp check shows that I've got no open ports. So that's all
> well and fine.
>
> However, if I improve things a bit and put myself through an
> INPUT-based, limited, local firewall like:
>
> Chain INPUT (policy ACCEPT)

<SNIP>

> Chain FORWARD (policy ACCEPT)
<SNIP>

> Chain OUTPUT (policy ACCEPT)
<SNIP>

Just wanted to comment on your configuration.
The usual procedure is to make the default policy for each chain to be
either DROP, or REJECT depending on your taste. You then pinhole only
what you want to go through. The INPUT and OUTPUT chains are for things
going to/from your PC. The FORWARD chain is used only where your PC is
acting as a gateway or router for other devices or networks. In the case
of a single PC connecting to the Internet, the FORWARD chain is not used.

Klazmon.

Llanzlan Klazmon wrote:
> Just wanted to comment on your configuration.
> The usual procedure is to make the default policy for each chain to be
> either DROP, or REJECT depending on your taste. You then pinhole only
> what you want to go through. The INPUT and OUTPUT chains are for things
> going to/from your PC. The FORWARD chain is used only where your PC is
> acting as a gateway or router for other devices or networks. In the case
> of a single PC connecting to the Internet, the FORWARD chain is not used.

Let's try and be more specific if I could.

This is currently what I'm using as a normal home user behind a cable
modem firewall NAT router with a static workstation address who needs
nothing more than VPN to office, web surfing, email, IRC chat, and FTP
download:

(replace MyDNS.com with the addresses found in /etc/resolv.conf)

1$ lokkit --disabled; # is necessary only on my workstation until I
uninstall lokkit and quit experimenting with it
2$ iptables -F
3$ iptables -A INPUT -i lo -j ACCEPT
4$ iptables -A INPUT -p tcp -m tcp --dport 500 --syn -j ACCEPT
5$ iptables -A INPUT -p udp -m udp --dport 500 -j ACCEPT
6$ iptables -A INPUT -p udp -m udp -s MyDNS.com --sport 53 -d 0/0 -j
ACCEPT
7$ iptables -A INPUT -p udp -m udp -s MyDNS.com --sport 53 -d 0/0 -j
ACCEPT
8$ iptables -A INPUT -p tcp -m tcp --syn -j REJECT
9$ iptables -A INPUT -p udp -m udp -j REJECT

And I think you've said:

* Drop line 4 because isakmp doesn't use tcp.
* Copy line 5 as line 4 and replace the port number with 4500 for
better compatibility with some VPNs -- only for those users who need
that, unless your VPN accepts this just fine.
* Append (or did you mean "prepend"?)

10$ iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
11$ iptables -A INPUT -p tcp --sport -m state --state ESTABLISHED -j
ACCEPT

* You also mentioned in your last statement that when I run these
commands and type "iptables -L", I get (policy ACCEPT) on each chain. I
think you implied that this might not be a good idea, so I was
wondering specifically what statements I must type to change that to
something that would work.

Thanks so much, Mr. Klazmon.

P.S. Readers, if you're on DHCP, not a static address, insert these
statements between lines 3 and 4 or your workstation will not renew
DHCP properly.

$ iptables -A INPUT -p udp -m udp -s 0/0 --sport 67:68 -d 0/0 --dport
67:68 -i eth0 -j ACCEPT
$ iptables -A INPUT -p udp -m udp -s 0/0 --sport 67:68 -d 0/0 --dport
67:68 -i eth1 -j ACCEPT

googlemike@hotpop.com wrote:
> Llanzlan Klazmon wrote:
>> Just wanted to comment on your configuration.
>> The usual procedure is to make the default policy for each chain to be
>> either DROP, or REJECT depending on your taste.
>
> Let's try and be more specific if I could.
>
> This is currently what I'm using as a normal home user behind a cable
> modem firewall NAT router with a static workstation address who needs
> nothing more than VPN to office, web surfing, email, IRC chat, and FTP
> download:

> 1$ lokkit --disabled; # is necessary only on my workstation until I
> uninstall lokkit and quit experimenting with it
> 2$ iptables -F
> 3$ iptables -A INPUT -i lo -j ACCEPT
> 4$ iptables -A INPUT -p tcp -m tcp --dport 500 --syn -j ACCEPT

'-m tcp' is unnecessary here. It doesn't hurt, but '... -p tcp --dport
500 ...' is easier.

Also note that it may be better to use '-m state NEW instead' of '--syn' -
while decent people will send SYNs for new connections and not send SYNs
for existing connections, that's not necessarily the case for crackers.

> 5$ iptables -A INPUT -p udp -m udp --dport 500 -j ACCEPT
> 6$ iptables -A INPUT -p udp -m udp -s MyDNS.com --sport 53 -d 0/0 -j
> ACCEPT
> 7$ iptables -A INPUT -p udp -m udp -s MyDNS.com --sport 53 -d 0/0 -j
> ACCEPT
> 8$ iptables -A INPUT -p tcp -m tcp --syn -j REJECT
> 9$ iptables -A INPUT -p udp -m udp -j REJECT

The intention here seems to be to reject everything. This is best
achieved by doing 'iptables -A INPUT -j REJECT'; not everything is TCP
or UDP, IPSec (commonly used for VPNs) for instance is not matched by
the above.

> * Drop line 4 because isakmp doesn't use tcp.
> * Copy line 5 as line 4 and replace the port number with 4500 for
> better compatibility with some VPNs -- only for those users who need
> that, unless your VPN accepts this just fine.

Those are good ideas.

> * Append (or did you mean "prepend"?)
>
> 10$ iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
> 11$ iptables -A INPUT -p tcp --sport -m state --state ESTABLISHED -j
> ACCEPT

This should, of course, read '... --sport 80 ...'; the above will give
you a syntax error.

> * You also mentioned in your last statement that when I run these
> commands and type "iptables -L", I get (policy ACCEPT) on each chain. I
> think you implied that this might not be a good idea, so I was
> wondering specifically what statements I must type to change that to
> something that would work.

iptables -P INPUT DROP
iptables -P OUTPUT REJECT
iptables -P FORWARD DROP

or something along these lines. I prefer REJECT to DROP, but there is
some argument on that topic.

> P.S. Readers, if you're on DHCP, not a static address, insert these
> statements between lines 3 and 4 or your workstation will not renew
> DHCP properly.
>
> $ iptables -A INPUT -p udp -m udp -s 0/0 --sport 67:68 -d 0/0 --dport
> 67:68 -i eth0 -j ACCEPT
> $ iptables -A INPUT -p udp -m udp -s 0/0 --sport 67:68 -d 0/0 --dport
> 67:68 -i eth1 -j ACCEPT

Erm... -s 0/0 means 'anywhere', as does -d 0/0. They don't hurt, but
they don't exactly help either... Additionally, you'll also want to
allow outgoing DHCP traffic.

Your configuration still allows all locally-initiated connections. While
this isn't too bad, it is quite a bit better to disallow those too.
Start with 'iptables -P OUTPUT DROP', and add allow rules until it
works. Don't forget state tracking (as used in #11 above).

Your configuration also does not allow active FTP; though active FTP is
rare, you'll want to allow it. To do this, allow inbound RELATED
connections (iptables -A INPUT -m state --state RELATED,ESTABLISHED -j
ACCEPT). ESTABLISHED is necessary, as RELATED only covers the first
packet of the data stream sent your way.

Joachim

googlemike@hotpop.com wrote in
news:1122291737.153077.303040@g43g2000cwa.googlegr oups.com:

> Llanzlan Klazmon wrote:
>> Just wanted to comment on your configuration.
>> The usual procedure is to make the default policy for each chain to
>> be either DROP, or REJECT depending on your taste. You then pinhole
>> only what you want to go through. The INPUT and OUTPUT chains are for
>> things going to/from your PC. The FORWARD chain is used only where
>> your PC is acting as a gateway or router for other devices or
>> networks. In the case of a single PC connecting to the Internet, the
>> FORWARD chain is not used.
>
> Let's try and be more specific if I could.
>
> This is currently what I'm using as a normal home user behind a cable
> modem firewall NAT router with a static workstation address who needs
> nothing more than VPN to office, web surfing, email, IRC chat, and FTP
> download:
>
> (replace MyDNS.com with the addresses found in /etc/resolv.conf)
>
> 1$ lokkit --disabled; # is necessary only on my workstation until I
> uninstall lokkit and quit experimenting with it
> 2$ iptables -F
> 3$ iptables -A INPUT -i lo -j ACCEPT
> 4$ iptables -A INPUT -p tcp -m tcp --dport 500 --syn -j ACCEPT
> 5$ iptables -A INPUT -p udp -m udp --dport 500 -j ACCEPT
> 6$ iptables -A INPUT -p udp -m udp -s MyDNS.com --sport 53 -d 0/0 -j
> ACCEPT
> 7$ iptables -A INPUT -p udp -m udp -s MyDNS.com --sport 53 -d 0/0 -j
> ACCEPT
> 8$ iptables -A INPUT -p tcp -m tcp --syn -j REJECT
> 9$ iptables -A INPUT -p udp -m udp -j REJECT
>
> And I think you've said:
>
> * Drop line 4 because isakmp doesn't use tcp.
> * Copy line 5 as line 4 and replace the port number with 4500 for
> better compatibility with some VPNs -- only for those users who need
> that, unless your VPN accepts this just fine.
> * Append (or did you mean "prepend"?)

Well you are mixing up what I said with what Joachim said. As I said, if
you are using a VPN that uses esp, you will also have to allow the esp
protocol. Some VPN's like OpenVPN allow you to run your VPN tunnel over a
tcp port using tls/ssl rather than IPSec which uses the esp protocol.

>
> 10$ iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
> 11$ iptables -A INPUT -p tcp --sport -m state --state ESTABLISHED -j
> ACCEPT

You want ESTABLISHED,RELATED otherwise the ftp protocol wont work
properly.




>
> * You also mentioned in your last statement that when I run these
> commands and type "iptables -L", I get (policy ACCEPT) on each chain.
> I think you implied that this might not be a good idea, so I was
> wondering specifically what statements I must type to change that to
> something that would work.

Joachim gave you the iptables commands to set the default policy on each
chain.

Klazmon.




>
> Thanks so much, Mr. Klazmon.
>
> P.S. Readers, if you're on DHCP, not a static address, insert these
> statements between lines 3 and 4 or your workstation will not renew
> DHCP properly.
>
> $ iptables -A INPUT -p udp -m udp -s 0/0 --sport 67:68 -d 0/0 --dport
> 67:68 -i eth0 -j ACCEPT
> $ iptables -A INPUT -p udp -m udp -s 0/0 --sport 67:68 -d 0/0 --dport
> 67:68 -i eth1 -j ACCEPT
>

Joachim Schipper wrote:
> googlemike@hotpop.com wrote:
>>googlemike@hotpop.com wrote:
>>>The following local firewall won't permit me to VPN...
> <snip>
>>>What do I need to do with iptables to poke my VPN connection through?
> <snip: works now, using...>
>>iptables -A INPUT -p tcp -m tcp --dport 500 --syn -j ACCEPT
>>iptables -A INPUT -p udp -m udp --dport 500 -j ACCEPT
>
> TCP is not required. IPSec often uses isakmp for key negotiation; this
> means port 500/udp. If you are using NAT-Traversal, you'll also require
> 4500/udp. You'll know if you're using NAT-T by the number of headaches
> setup caused you... ;-)
If your office IPSec hub is using the older Altiga NAT Traversal in
UDP/TCP you may need TCP/UDP 10000 opened up. But as previously stated
you would most probably know if this was the case.