VPN rules

VPN rules

[Eduardo Ukstin]

Hi

I´m trying to configure a subnet into my network to access a VPN
outside here. The vpn uses port 500, just the forward rules doesn´t
seem to work, my rule was this

iptables -A INPUT -i eth1 -p tcp -s xx.xx.xx.xx/24 --dport 500 -j
ACCEPT (after a established, related rule)

and

iptables -A FORWARD -i eth1 -s xx.xx.xx.xx/24 -p tcp --dport 500 -j
ACCEPT (also, after a established, related rule)

I think its enough, and sometimes the stations could connect very
well, but now, the vpn client start the connection and after the user
and password requisition he starts to try a reconnection.

I read something about protocol 47 (option -p 47) I need to use it?
Need some special patch in iptables or what?

Thanks a lot

--
Eduardo Ukstin
GNU/Linux User #328388

RE: VPN rules

[P. Harlow]

It depends on the type of VPN you are using.

IPSec based VPNs typically use:

UDP 500 - IPSec negotiation
IP 51 - Authentication Header (AH) for IPSec negotiation
IP 50 - IPSec data

PPTP based VPNs typically use:

IP 47 - General Routing Encapsulation (GRE)PPTP data channel
TCP 1723 - PPTP control channel

You are going to want to figure out which type of VPN you are using and
allow for those ports. I would assume that since you're getting
authentication requests with port 500 open however your TCP 500 causes me to
wonder what type of VPN you have.

-----Original Message-----
From: netfilter-bounces@lists.netfilter.org
[mailto:netfilter-bounces@lists.netfilter.org] On Behalf Of Eduardo Ukstin
Sent: Wednesday, January 04, 2006 3:18 PM
To: netfilter@lists.netfilter.org
Subject: VPN rules

Hi

I´m trying to configure a subnet into my network to access a VPN
outside here. The vpn uses port 500, just the forward rules doesn´t
seem to work, my rule was this

iptables -A INPUT -i eth1 -p tcp -s xx.xx.xx.xx/24 --dport 500 -j
ACCEPT (after a established, related rule)

and

iptables -A FORWARD -i eth1 -s xx.xx.xx.xx/24 -p tcp --dport 500 -j
ACCEPT (also, after a established, related rule)

I think its enough, and sometimes the stations could connect very
well, but now, the vpn client start the connection and after the user
and password requisition he starts to try a reconnection.

I read something about protocol 47 (option -p 47) I need to use it?
Need some special patch in iptables or what?

Thanks a lot

--
Eduardo Ukstin
GNU/Linux User #328388

Re: VPN rules

[Eduardo Ukstin]

I've created some rules to see what the vpn client is trying to do,
and saw some interesting things.

In the negociation the client goes throw the vpn server (outside my
lan) and everything works, but after this, it tries to ping a
192.43... ip, my firewall doesn't rotate this, and of course this ping
requisition cannot goes through. But I'm a little confused about what
to do, create a route for this 192 or make a prerouting rule, in any
of this cases I'm not certain of what I need to do.

My internal network has ip 10.....

On 1/4/06, P. Harlow <wolf-r1@wispertel.net> wrote:
> It depends on the type of VPN you are using.
>
> IPSec based VPNs typically use:
>
> UDP 500 - IPSec negotiation
> IP 51 - Authentication Header (AH) for IPSec negotiation
> IP 50 - IPSec data
>
> PPTP based VPNs typically use:
>
> IP 47 - General Routing Encapsulation (GRE)PPTP data channel
> TCP 1723 - PPTP control channel
>
> You are going to want to figure out which type of VPN you are using and
> allow for those ports. I would assume that since you're getting
> authentication requests with port 500 open however your TCP 500 causes me to
> wonder what type of VPN you have.
>

Re: VPN rules

[Eduardo Ukstin]

Yes,

iptables -A INPUT -p 47 ... (or gre)
iptables -A INPUT -p 50 ...
iptables -A INPUT -p 51 ...

and none of these received any package. I'm afraid this is a
proprietary vpn, at least the client is.

Thanks

On 1/5/06, Sp0oKeR <spooker@gmail.com> wrote:
>  Did you allow gre protocol ?
>  Some rule like:
>
>  iptables-I INPUT -p gre ......
>
>
> Regards,
>
>
> On 1/5/06, Eduardo Ukstin <ukstin@gmail.com> wrote:
> > I've created some rules to see what the vpn client is trying to do,
> > and saw some interesting things.
> >
> > In the negociation the client goes throw the vpn server (outside my
> > lan) and everything works, but after this, it tries to ping a
> > 192.43... ip, my firewall doesn't rotate this, and of course this ping
> > requisition cannot goes through. But I'm a little confused about what
> > to do, create a route for this 192 or make a prerouting rule, in any
> > of this cases I'm not certain of what I need to do.
> >
> > My internal network has ip 10.....
> >
> > On 1/4/06, P. Harlow <wolf-r1@wispertel.net> wrote:
> > > It depends on the type of VPN you are using.
> > >
> > > IPSec based VPNs typically use:
> > >
> > > UDP 500 - IPSec negotiation
> > > IP 51 - Authentication Header (AH) for IPSec negotiation
> > > IP 50 - IPSec data
> > >
> > > PPTP based VPNs typically use:
> > >
> > > IP 47 - General Routing Encapsulation (GRE)PPTP data channel
> > > TCP 1723 - PPTP control channel
> > >
> > > You are going to want to figure out which type of VPN you are using and
> > > allow for those ports. I would assume that since you're getting
> > > authentication requests with port 500 open however your TCP 500 causes me to
> > > wonder what type of VPN you have.
> > >
> >
> >
>
>
> --
> =====================
>  Rodrigo Ribeiro Montoro
> Desenvolvedor BRMAlinux
>  spooker@brc.com.br
>       RHCE/LPIC-I
> =====================
>


--
Eduardo Ukstin
GNU/Linux User #328388

Re: VPN rules

[/dev/rob0]

On Thursday 2006-January-05 06:31, Eduardo Ukstin wrote:
> iptables -A INPUT -p 47 ... (or gre)
> iptables -A INPUT -p 50 ...
> iptables -A INPUT -p 51 ...
>
> and none of these received any package. I'm afraid this is a
> proprietary vpn, at least the client is.

You will have to ask the vendor for information, or do some low-level 
investigation (i.e., packet sniffing) on your own.

Or, of course, switch to something open and documented on both ends. 
OpenVPN is my top choice for VPN.
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header