Hello Bjoern,
Friday, July 30, 2004, 11:02:26 AM, Bjoern A. Zeeb wrote:
>> Then I do (on VPN_router2):
>> bash-2.05b# uname -sr
>> FreeBSD 4.9-RELEASE
BAZ> ok; for the 'ipsec' ipfw option this is too old. It's been functional
BAZ> in 5.x since 2003-12-02, that is 5.2, 5.2.1, HEAD and in RELENG_4 since
BAZ> 2004-01-22 that is 4.10 includes it but 4.9-RELEASE does not.
any improvements in ipfw or ipfw2 don't really help, because the
original (not encrypted) packet just doesnt reach ipfw on the second
(output) pass. More on this below.
>> after 4 pings from 217.195.82.43 to 192.168.64.10:
>>
>> bash-2.05b# ipfw sh 1
>> 00001 4 240 count icmp from 192.168.64.10 to 217.195.82.43 in
>> 00001 0 0 count icmp from 192.168.64.10 to 217.195.82.43 out
>>
>> while it obviously should be 4 of them in both rules.
BAZ> no.
BAZ> if you ping from 217.195.82.43 to 192.168.64.10 it should be like
BAZ> that on vpn_router2 (not ipsec option yet as you cannot use it):
BAZ> ipfw add 1 count icmp from 217.195.82.43 to 192.168.64.10 in recv $int_outside
BAZ> # expecting 0 matches
BAZ> ipfw add 1 count esp from 217.195.82.43 to 192.168.64.10 in recv $int_outside
BAZ> # expecting 4 amtches
I think I have got your point here, but filtering esp in tunnel mode
is of no use in many scenarios since higher protocol information (like
ports for TCP/UDP) is hidden in encrypted payload.
>> natd translates rewrites src addr only on outgoing packets, but the
>> outgoing packets never reach natd, because they don't make it thru
>> ipfw rules. Tricky, eh? So I see 3 choices so far:
>> 1. patch libalias
>> 2. patch the kernel (ip_output.c ? ip_fw.c? )
>> 3. use two separate boxes for nating and ipsekking.
BAZ> no, no, no.
BAZ> filter on your inside interface and divert packets there; this way
BAZ> nat is done before reaching output and thus before ipsec.
Correct me if I am wrong but diverting incoming packets wont help.
Libalias will just pass them unNATed. Or has it been changed since
4.9? Let's see.
alias.c, Revision 1.48(latest):
static int
TcpAliasIn(struct libalias *la, struct ip *pip)
{
struct tcphdr *tc;
struct alias_link *lnk;
tc = (struct tcphdr *)ip_next(pip);
lnk = FindUdpTcpIn(la, pip->ip_src, pip->ip_dst,
tc->th_sport, tc->th_dport,
IPPROTO_TCP,
!(la->packetAliasMode & PKT_ALIAS_PROXY_ONLY));
if (lnk != NULL) { //match found in table
.
.
various checks and restoring src/dst address from
table)
.
.
}
return (PKT_ALIAS_IGNORED);
}
see? if the incoming packet is not in table, _and_ natd is not running
in proxy_only mode (which is not acceptable here) the packet flows by
without any change. And that's what the `man natd' says.
BAZ> In the other direction packet are first run through ipsec getting you
BAZ> the IP packet (that then will have an ipsec history you can match with
BAZ> an up-to-date release) and when leaving the machine to your inside
BAZ> network will be natted back.
Yes. This part works great :)
BAZ> The ruleset gets quite tricky then but it works here (HEAD from about
BAZ> 82 days ago according to uptime ;-)
? Do you mean you have the same scenario? And diverting on inside
interface works for you?
--
Best regards,
; Nickolay A. Kritsky
; SysAdmin STAR Software LLC
; mailto:[EMAIL PROTECTED]
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
