All of lore.kernel.org
 help / color / mirror / Atom feed
* PPTP NAT module
@ 2003-12-09 23:03 Joshua Jackson
  2003-12-11 15:57 ` Oleg Savostyanov
  0 siblings, 1 reply; 7+ messages in thread
From: Joshua Jackson @ 2003-12-09 23:03 UTC (permalink / raw)
  To: netfilter

I know there have been a pile of questions about this module in the past, but 
I can't seem to find any responses about the behaviour I am seeing.

I am currently running a 2.4.23 kernel with the lastest officially released 
POM patches applied to it. The network being protected by the firewall is 
providing NAT for the hosts behind it. If the ip_nat_pptp module is loaded, 
none of the protected clients can establish an outbound PPTP session. If the 
conntrack modules are removed, a single session can be established (as would 
be expected).

The remote PPTP server log shows the initial TCP connection, but never sees 
any GRE traffic from the connecting host.

I have seen posts about the local NAT kernel option, I have tried it both ways 
with the same results. If there are any kernel settings in particular that I 
may be missing, please let me know.

My iptables firewall rules include a default policy of DROP for INPUT and 
FORWARD, ACCEPT for OUTPUT. The first line in the rules includes an ACCEPT 
for the INPUT chain for established and related connection. There is also a 
rule allowing any traffic for all protocols to any host which originates from 
the protected network on the internal interface.

-- 
Joshua Jackson
Vortech Consulting
http://www.vortech.net



^ permalink raw reply	[flat|nested] 7+ messages in thread

* PPTP Nat Module
@ 2003-12-10  2:39 Joshua Jackson
  2003-12-10  3:24 ` Philip Craig
  0 siblings, 1 reply; 7+ messages in thread
From: Joshua Jackson @ 2003-12-10  2:39 UTC (permalink / raw)
  To: netfilter

I know there have been a pile of questions about this module in the past, but 
I can't seem to find any responses about the behaviour I am seeing.

I am currently running a 2.4.23 kernel with the lastest officially released 
POM patches applied to it. The network being protected by the firewall is 
providing NAT for the hosts behind it. If the ip_nat_pptp module is loaded, 
none of the protected clients can establish an outbound PPTP session. If the 
conntrack modules are removed, a single session can be established (as would 
be expected).

The remote PPTP server log shows the initial TCP connection, but never sees 
any GRE traffic from the connecting host.

I have seen posts about the local NAT kernel option, I have tried it both ways 
with the same results. If there are any kernel settings in particular that I 
may be missing, please let me know.

My iptables firewall rules include a default policy of DROP for INPUT and 
FORWARD, ACCEPT for OUTPUT. The first line in the rules includes an ACCEPT 
for the INPUT chain for established and related connection. There is also a 
rule allowing any traffic for all protocols to any host which originates from 
the protected network on the internal interface.

-- 
Joshua Jackson
Vortech Consulting
http://www.vortech.net



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: PPTP Nat Module
  2003-12-10  2:39 PPTP Nat Module Joshua Jackson
@ 2003-12-10  3:24 ` Philip Craig
  2003-12-10 18:17   ` Joshua Jackson
  0 siblings, 1 reply; 7+ messages in thread
From: Philip Craig @ 2003-12-10  3:24 UTC (permalink / raw)
  To: Joshua Jackson; +Cc: netfilter

Joshua Jackson wrote:
> My iptables firewall rules include a default policy of DROP for INPUT and 
> FORWARD, ACCEPT for OUTPUT. The first line in the rules includes an ACCEPT 
> for the INPUT chain for established and related connection. There is also a 
> rule allowing any traffic for all protocols to any host which originates from 
> the protected network on the internal interface.

Do you an ACCEPT for the FORWARD chain for established and related connections?

-- 
Philip Craig - SnapGear, A CyberGuard Company - http://www.SnapGear.com



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: PPTP Nat Module
  2003-12-10  3:24 ` Philip Craig
@ 2003-12-10 18:17   ` Joshua Jackson
  0 siblings, 0 replies; 7+ messages in thread
From: Joshua Jackson @ 2003-12-10 18:17 UTC (permalink / raw)
  To: Philip Craig; +Cc: netfilter

On Tuesday 09 December 2003 22:24, Philip Craig wrote:
> Joshua Jackson wrote:
> > My iptables firewall rules include a default policy of DROP for INPUT and
> > FORWARD, ACCEPT for OUTPUT. The first line in the rules includes an
> > ACCEPT for the INPUT chain for established and related connection. There
> > is also a rule allowing any traffic for all protocols to any host which
> > originates from the protected network on the internal interface.
>
> Do you an ACCEPT for the FORWARD chain for established and related
> connections?

Yes, it also accepts established and related connections.



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: PPTP NAT module
  2003-12-09 23:03 PPTP NAT module Joshua Jackson
@ 2003-12-11 15:57 ` Oleg Savostyanov
  2003-12-11 16:49   ` Joshua Jackson
  2003-12-20  4:14   ` Joshua Jackson
  0 siblings, 2 replies; 7+ messages in thread
From: Oleg Savostyanov @ 2003-12-11 15:57 UTC (permalink / raw)
  To: netfilter

Hello Joshua,
I successfully installed on a 2.4.23 kernel with ip_nat_pptp module
I tested 3 vpn NATed connections to the SAME! server in the outside world
see below my kernel's .config

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
# CONFIG_NETLINK_DEV is not set
CONFIG_NETFILTER=y
CONFIG_NETFILTER_DEBUG=y
CONFIG_FILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_FWMARK=y
CONFIG_IP_ROUTE_NAT=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_TOS=y
CONFIG_IP_ROUTE_VERBOSE=y
CONFIG_IP_PNP=y
# CONFIG_IP_PNP_DHCP is not set
# CONFIG_IP_PNP_BOOTP is not set
CONFIG_NET_IPIP=y
CONFIG_NET_IPGRE=y
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
CONFIG_ARPD=y
CONFIG_INET_ECN=y
# CONFIG_SYN_COOKIES is not set

#
#   IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=y
CONFIG_IP_NF_FTP=y
# CONFIG_IP_NF_AMANDA is not set
CONFIG_IP_NF_TFTP=y
CONFIG_IP_NF_IRC=y
CONFIG_IP_NF_CT_PROTO_GRE=y
CONFIG_IP_NF_PPTP=y
CONFIG_IP_NF_QUEUE=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_LIMIT=y
CONFIG_IP_NF_MATCH_MAC=y
# CONFIG_IP_NF_MATCH_PKTTYPE is not set
CONFIG_IP_NF_MATCH_MARK=y
CONFIG_IP_NF_MATCH_MULTIPORT=y
CONFIG_IP_NF_MATCH_TOS=y
# CONFIG_IP_NF_MATCH_RECENT is not set
# CONFIG_IP_NF_MATCH_ECN is not set
# CONFIG_IP_NF_MATCH_DSCP is not set
CONFIG_IP_NF_MATCH_AH_ESP=y
CONFIG_IP_NF_MATCH_LENGTH=y
CONFIG_IP_NF_MATCH_TTL=y
CONFIG_IP_NF_MATCH_TCPMSS=y
CONFIG_IP_NF_MATCH_HELPER=y
CONFIG_IP_NF_MATCH_STATE=y
CONFIG_IP_NF_MATCH_CONNTRACK=y
CONFIG_IP_NF_MATCH_UNCLEAN=y
CONFIG_IP_NF_MATCH_OWNER=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_MIRROR=y
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_REDIRECT=y
CONFIG_IP_NF_NAT_PPTP=y
CONFIG_IP_NF_NAT_PROTO_GRE=y
# CONFIG_IP_NF_NAT_LOCAL is not set
CONFIG_IP_NF_NAT_SNMP_BASIC=y
CONFIG_IP_NF_NAT_IRC=y
CONFIG_IP_NF_NAT_FTP=y
CONFIG_IP_NF_NAT_TFTP=y
CONFIG_IP_NF_MANGLE=y
CONFIG_IP_NF_TARGET_TOS=y
# CONFIG_IP_NF_TARGET_ECN is not set
# CONFIG_IP_NF_TARGET_DSCP is not set
CONFIG_IP_NF_TARGET_MARK=y
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IP_NF_TARGET_ULOG=y
CONFIG_IP_NF_TARGET_TCPMSS=y
CONFIG_IP_NF_ARPTABLES=y
CONFIG_IP_NF_ARPFILTER=y
CONFIG_IP_NF_ARP_MANGLE=y




Wednesday, December 10, 2003, 2:03:55 AM, you wrote:

JJ> I know there have been a pile of questions about this module in the past, but
JJ> I can't seem to find any responses about the behaviour I am seeing.

JJ> I am currently running a 2.4.23 kernel with the lastest officially released
JJ> POM patches applied to it. The network being protected by the firewall is
JJ> providing NAT for the hosts behind it. If the ip_nat_pptp module is loaded,
JJ> none of the protected clients can establish an outbound PPTP session. If the
JJ> conntrack modules are removed, a single session can be established (as would
JJ> be expected).

JJ> The remote PPTP server log shows the initial TCP connection, but never sees
JJ> any GRE traffic from the connecting host.

JJ> I have seen posts about the local NAT kernel option, I have tried it both ways
JJ> with the same results. If there are any kernel settings in particular that I
JJ> may be missing, please let me know.

JJ> My iptables firewall rules include a default policy of DROP for INPUT and
JJ> FORWARD, ACCEPT for OUTPUT. The first line in the rules includes an ACCEPT
JJ> for the INPUT chain for established and related connection. There is also a
JJ> rule allowing any traffic for all protocols to any host which originates from
JJ> the protected network on the internal interface.



-- 
Best regards,
 Oleg                            mailto:savostyanov@internetplustravel.ru



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: PPTP NAT module
  2003-12-11 15:57 ` Oleg Savostyanov
@ 2003-12-11 16:49   ` Joshua Jackson
  2003-12-20  4:14   ` Joshua Jackson
  1 sibling, 0 replies; 7+ messages in thread
From: Joshua Jackson @ 2003-12-11 16:49 UTC (permalink / raw)
  To: Oleg Savostyanov, netfilter

Thanks. I will build a kernel from your config and give it a go.

Josh

On Thursday 11 December 2003 10:57, Oleg Savostyanov wrote:
> Hello Joshua,
> I successfully installed on a 2.4.23 kernel with ip_nat_pptp module
> I tested 3 vpn NATed connections to the SAME! server in the outside world
> see below my kernel's .config
>
> #
> # Networking options
> #
> CONFIG_PACKET=y
> CONFIG_PACKET_MMAP=y
> # CONFIG_NETLINK_DEV is not set
> CONFIG_NETFILTER=y
> CONFIG_NETFILTER_DEBUG=y
> CONFIG_FILTER=y
> CONFIG_UNIX=y
> CONFIG_INET=y
> CONFIG_IP_MULTICAST=y
> CONFIG_IP_ADVANCED_ROUTER=y
> CONFIG_IP_MULTIPLE_TABLES=y
> CONFIG_IP_ROUTE_FWMARK=y
> CONFIG_IP_ROUTE_NAT=y
> CONFIG_IP_ROUTE_MULTIPATH=y
> CONFIG_IP_ROUTE_TOS=y
> CONFIG_IP_ROUTE_VERBOSE=y
> CONFIG_IP_PNP=y
> # CONFIG_IP_PNP_DHCP is not set
> # CONFIG_IP_PNP_BOOTP is not set
> CONFIG_NET_IPIP=y
> CONFIG_NET_IPGRE=y
> CONFIG_NET_IPGRE_BROADCAST=y
> CONFIG_IP_MROUTE=y
> CONFIG_IP_PIMSM_V1=y
> CONFIG_IP_PIMSM_V2=y
> CONFIG_ARPD=y
> CONFIG_INET_ECN=y
> # CONFIG_SYN_COOKIES is not set
>
> #
> #   IP: Netfilter Configuration
> #
> CONFIG_IP_NF_CONNTRACK=y
> CONFIG_IP_NF_FTP=y
> # CONFIG_IP_NF_AMANDA is not set
> CONFIG_IP_NF_TFTP=y
> CONFIG_IP_NF_IRC=y
> CONFIG_IP_NF_CT_PROTO_GRE=y
> CONFIG_IP_NF_PPTP=y
> CONFIG_IP_NF_QUEUE=y
> CONFIG_IP_NF_IPTABLES=y
> CONFIG_IP_NF_MATCH_LIMIT=y
> CONFIG_IP_NF_MATCH_MAC=y
> # CONFIG_IP_NF_MATCH_PKTTYPE is not set
> CONFIG_IP_NF_MATCH_MARK=y
> CONFIG_IP_NF_MATCH_MULTIPORT=y
> CONFIG_IP_NF_MATCH_TOS=y
> # CONFIG_IP_NF_MATCH_RECENT is not set
> # CONFIG_IP_NF_MATCH_ECN is not set
> # CONFIG_IP_NF_MATCH_DSCP is not set
> CONFIG_IP_NF_MATCH_AH_ESP=y
> CONFIG_IP_NF_MATCH_LENGTH=y
> CONFIG_IP_NF_MATCH_TTL=y
> CONFIG_IP_NF_MATCH_TCPMSS=y
> CONFIG_IP_NF_MATCH_HELPER=y
> CONFIG_IP_NF_MATCH_STATE=y
> CONFIG_IP_NF_MATCH_CONNTRACK=y
> CONFIG_IP_NF_MATCH_UNCLEAN=y
> CONFIG_IP_NF_MATCH_OWNER=y
> CONFIG_IP_NF_FILTER=y
> CONFIG_IP_NF_TARGET_REJECT=y
> CONFIG_IP_NF_TARGET_MIRROR=y
> CONFIG_IP_NF_NAT=y
> CONFIG_IP_NF_NAT_NEEDED=y
> CONFIG_IP_NF_TARGET_MASQUERADE=y
> CONFIG_IP_NF_TARGET_REDIRECT=y
> CONFIG_IP_NF_NAT_PPTP=y
> CONFIG_IP_NF_NAT_PROTO_GRE=y
> # CONFIG_IP_NF_NAT_LOCAL is not set
> CONFIG_IP_NF_NAT_SNMP_BASIC=y
> CONFIG_IP_NF_NAT_IRC=y
> CONFIG_IP_NF_NAT_FTP=y
> CONFIG_IP_NF_NAT_TFTP=y
> CONFIG_IP_NF_MANGLE=y
> CONFIG_IP_NF_TARGET_TOS=y
> # CONFIG_IP_NF_TARGET_ECN is not set
> # CONFIG_IP_NF_TARGET_DSCP is not set
> CONFIG_IP_NF_TARGET_MARK=y
> CONFIG_IP_NF_TARGET_LOG=y
> CONFIG_IP_NF_TARGET_ULOG=y
> CONFIG_IP_NF_TARGET_TCPMSS=y
> CONFIG_IP_NF_ARPTABLES=y
> CONFIG_IP_NF_ARPFILTER=y
> CONFIG_IP_NF_ARP_MANGLE=y
>
>
>
>
> Wednesday, December 10, 2003, 2:03:55 AM, you wrote:
>
> JJ> I know there have been a pile of questions about this module in the
> past, but JJ> I can't seem to find any responses about the behaviour I am
> seeing.
>
> JJ> I am currently running a 2.4.23 kernel with the lastest officially
> released JJ> POM patches applied to it. The network being protected by the
> firewall is JJ> providing NAT for the hosts behind it. If the ip_nat_pptp
> module is loaded, JJ> none of the protected clients can establish an
> outbound PPTP session. If the JJ> conntrack modules are removed, a single
> session can be established (as would JJ> be expected).
>
> JJ> The remote PPTP server log shows the initial TCP connection, but never
> sees JJ> any GRE traffic from the connecting host.
>
> JJ> I have seen posts about the local NAT kernel option, I have tried it
> both ways JJ> with the same results. If there are any kernel settings in
> particular that I JJ> may be missing, please let me know.
>
> JJ> My iptables firewall rules include a default policy of DROP for INPUT
> and JJ> FORWARD, ACCEPT for OUTPUT. The first line in the rules includes an
> ACCEPT JJ> for the INPUT chain for established and related connection.
> There is also a JJ> rule allowing any traffic for all protocols to any host
> which originates from JJ> the protected network on the internal interface.



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: PPTP NAT module
  2003-12-11 15:57 ` Oleg Savostyanov
  2003-12-11 16:49   ` Joshua Jackson
@ 2003-12-20  4:14   ` Joshua Jackson
  1 sibling, 0 replies; 7+ messages in thread
From: Joshua Jackson @ 2003-12-20  4:14 UTC (permalink / raw)
  To: Oleg Savostyanov, netfilter

On Thursday 11 December 2003 10:57, Oleg Savostyanov wrote:
> Hello Joshua,
> I successfully installed on a 2.4.23 kernel with ip_nat_pptp module
> I tested 3 vpn NATed connections to the SAME! server in the outside world
> see below my kernel's .config
>
<snip>

It would appear that the PPTP NAT connection tracking code only works if it is 
built directly into the kernel. With it loaded as a module, I can not get a 
single PPTP connection through the firewall. With it built in, the connection 
tracking works as it should.

I would like to have it available as a module to give people the option of 
loading it only if they need it... but for now, at least it is working.

--
Joshua Jackson
Vortech Consulting
http://www.vortech.net



^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2003-12-20  4:14 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-12-10  2:39 PPTP Nat Module Joshua Jackson
2003-12-10  3:24 ` Philip Craig
2003-12-10 18:17   ` Joshua Jackson
  -- strict thread matches above, loose matches on Subject: below --
2003-12-09 23:03 PPTP NAT module Joshua Jackson
2003-12-11 15:57 ` Oleg Savostyanov
2003-12-11 16:49   ` Joshua Jackson
2003-12-20  4:14   ` Joshua Jackson

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.