From owner-freebsd-pf@FreeBSD.ORG Tue Nov 2 13:53:33 2004 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF7CE16A4CE for ; Tue, 2 Nov 2004 13:53:33 +0000 (GMT) Received: from spoolo3.tiscali.be (spoolo3.tiscali.be [62.235.13.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D90D43D5C for ; Tue, 2 Nov 2004 13:53:32 +0000 (GMT) (envelope-from cedric@virtual-globe.net) Received: from [83.134.149.196] (helo=note01.echo.decemplex.loc) by spoolo3.tiscali.be with esmtp (Tiscali.be http://www.tiscali.be) id 1COz6J-0001fJ-94 for ; Tue, 02 Nov 2004 14:53:31 +0100 Date: Tue, 2 Nov 2004 14:53:16 +0100 From: =?ISO-8859-15?B?Q+lkcmljIEpvbmFz?= X-Mailer: The Bat! (v2.11.02) X-Priority: 3 (Normal) Message-ID: <938471846.20041102145316@virtual-globe.net> To: freebsd-pf MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Subject: NAT Loopback X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: =?ISO-8859-15?B?Q+lkcmljIEpvbmFz?= List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2004 13:53:33 -0000 Hi freebsd-pf, Since 5 days, I try to install PF on my Server, to replace my old hardware router... Until now, everything was ok, better als the old router - BUT, what I miss is the NAT Loopback functionnality (so that IP packets which comes from the LAN and are destined to my WAN IP, leaves effectively the WAN interface and come back through the WAN interface => the packet is subjected to the filter rulesets for incoming packets on my WAN interface = NAT Loopback) I found this in the OpenBSD PF FAQ: http://www.openbsd.org/faq/pf/rdr.html#rdrnat, but it isn't what I search, because the packets don't leave and reentry the WAN interface. So I try following: I blocked incoming Telnet connections on my WAN interface, and start a telnet to my WAN IP from a host on my LAN, telnet was successfull... so that isn't what I want. After a tcpdump on my 2 WAN and LAN interface (fxp0 and tun0 on the FreeBSD router), I noted that the server accepts already the telnet connection at fxp0, so I can see an incoming packet to my WAN IP, but nothing more, because it's already accepted here. Why? After some researchs, I found out that the TCP/IP stack on the router compares the destination address with his own interfaces and aliases - if one agrees, he accept the connection. Next test: with the same ruleset, I start a telnet on my WAN IP from the router, here the connection was blocked, and thanks tcpdump I see that the IP packet leaves tun0, come back - and was successfully blocked (packet had the WAN IP as source AND destination address). So, in conclusion, I try a nat rule on fxp0, the LAN interface: nat on fxp0 inet from fxp0:network to (tun0) -> (tun0) So that incoming connection on this interface, out the LAN, get the WAN IP was source address... but one more time, telnet from the LAN was successfull, the packet doesn't leave tun0, and was already accepted on fxp0. I don't know if it's really possible to realize NAT Loopback with PF, if yes, do you have experience with it? Or is it possible to oblige FreeBSD/PF to only accept connections with the same destination address as the IP address from the interface where the packet comes in (so that a comparison with every interface IP does not take place)? In resume, that's what I want: 000509 rule 2/0(match): pass out on tun0: IP 83.134.149.196.63347 > 83.134.149.196.23: S 1094509118:1094509118(0) win 65535 000249 rule 0/0(match): block in on tun0: IP 83.134.149.196.63347 > 83.134.149.196.23: S 1094509118:1094509118(0) win 65535 That's from a tcpdump after a telnet connection to my WAN IP from the router... but in case of a telnet from a LAN host to the WAN IP, the only thing I was able to log was: 555257 rule 5/0(match): pass in on fxp0: IP 192.168.0.99.1547 > 83.134.149.196.23: S 377131760:377131760(0) win 16384 ... and the connection was accepted here - I wish to have the same "effect" here as above... a NAT Loopback. I hope that one will be able to help me here (and that I described it understandably), it's my last possibility I think. Sorry for my bad englisch, but I do what I can ;-) -- Best regards, Cédric Jonas Courriel : cedric@virtual-globe.net Post-Joint : .