[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cobalt-users] Qube3 - Remote Access VPN
- Subject: Re: [cobalt-users] Qube3 - Remote Access VPN
- From: Malcolm McLeary <mmcleary@xxxxxxx>
- Date: Tue Jan 6 23:37:01 2004
- List-id: Mailing list for users to share thoughts on Sun Cobalt products. <cobalt-users.list.cobalt.com>
Hi Guys,
on 6/1/04 8:01 AM, Malcolm McLeary wrote:
> I have a Qube3 set up as firewall for a small network via the Basic Firewall
> capability. Users on the inside are able to establish VPN connections to
> remote servers, but I'm not having any success establishing a VPN from the
> outside back in.
>
> To get access to remote VPN servers I had to manually add a rule to
> ipchains.conf to allow protocol 47 through but the only way to get a
> connection the other way is to disable the Basic Firewall.
>
> Port 1723 is open so I can establish a connection, but I can't get any
> traffic to flow ... this happens with protocol 47.
>
> Obviously ipchains is blocking the traffic, but I can't see why it is only
> happening one way.
Problem solved!
I was confused by the fact that outbound Remote VPN worked, but inbound
didn't. What I overlooked was the fact that although an inbound VPN
connection comes in via eth1 the traffic actually appears to come from a
virtual interface ... ppp0.
Hence apart from rules for tcp traffic on port 1723 and a manual rule in
ipchains.conf such that protocol 47 (i.e. GRE) is accepted you also need a
rule to accept all traffic on ppp0.
The ipchains rules I added manually look like this;
# Protocol 47 (GRE) is required for PPTP
/sbin/ipchains -A input -p 47 -s 0.0.0.0/0 -d 0.0.0.0/0 -j ACCEPT
# Accepting traffic on ppp0 (i.e. Virtual Interface) is required for PPTP
/sbin/ipchains -A input -p all -s 0.0.0.0/0 -d 0.0.0.0/0 -i ppp0 -j ACCEPT
An alternative solution is to have a default policy of accept and then have
rules to deny specific things, but I prefer the default to be deny on the
exposed interface and then enable things.
Cheers, Malcolm