Kage wrote:
I'm sorry, I did not understand what you just asked.
When the request hit the real server [72.20.28.202], the response from
this server must go back to the natd server so the reverse translation
can take place. You can check by running tcpdump on [207.210.114.45] and
see if the response came back from [72.20.28.202].
On Tue, Mar 25, 2008 at 11:23 AM, Henri Hennebert <[EMAIL PROTECTED]> wrote:
Kage wrote:
> I changed my rules, and it's still not working:
>
> $IPF 50220 divert natd all from 72.20.28.202 6667 to any via rl0
> $IPF 50221 divert natd all from any to 207.210.114.45 6667 via rl0
>
> It's still timing connections out.
Does the server hosting natd is the default route for 72.20.28.202 ?
Henri
>
On Mon, Mar 24, 2008 at 4:24 PM, Henri Hennebert <[EMAIL PROTECTED]> wrote:
>> Kage wrote:
>> > Still not working, but I DO have natd aliasing properly. Here's my
>> > natd output (remember which IP is mine, the IRC jail, and the example
>> > round-robin IP):
>> >
>> > [EMAIL PROTECTED] /etc]# natd -f /etc/natd.conf
>> > In {default}[TCP] [TCP] 72.65.73.23:2897 -> 207.210.114.45:6667
aliased to
>> >[TCP] 72.65.73.23:2897 -> 72.20.28.202:6667
>> > In {default}[TCP] [TCP] 72.65.73.23:2897 -> 207.210.114.45:6667
aliased to
>> >[TCP] 72.65.73.23:2897 -> 72.20.28.202:6667
>> > In {default}[TCP] [TCP] 72.65.73.23:2897 -> 207.210.114.45:6667
aliased to
>> >[TCP] 72.65.73.23:2897 -> 72.20.28.202:6667
>> >
>> > 72...23 (me) is hitting the natd on the jail IP (207...45), which is
>> > getting correctly aliased to 72...202 (example round-robin IP). So it
>> > appears the natd is working properly.
>>
>> In the client -> server direction only for now -- see bellow.
>>
>>
>>
>> > Here's my natd configuration as
>> > it exists now:
>> >
>> > # Nub.Core NATd
>> > verbose
>> > alias_address 207.210.114.45
>> > log
>> > log_denied
>> > log_ipfw_denied
>> > pid_file /var/run/natd.pid
>> >
>> > ### IRC Redirect Ports
>> > # 6667
>> > redirect_port tcp 72.20.28.202:6667 207.210.114.45:6667
>> >
>> > And for more record, here's my ipfw.rules file up until the divert:
>> >
>> > [EMAIL PROTECTED] /etc]# cat ipfw.rules
>> > IPF="ipfw -q add"
>> > ipfw -f -q flush
>> >
>> > #loopback
>> > $IPF 10 allow all from any to any via lo0
>> > $IPF 20 deny all from any to 127.0.0.0/8
>> > $IPF 30 deny all from 127.0.0.0/8 to any
>> > $IPF 40 deny tcp from any to any frag
>> >
>> > # statefull
>> > $IPF 50 check-state
>> > $IPF 60 allow tcp from any to any established
>> > $IPF 70 allow all from any to any out keep-state
>> > $IPF 54999 allow icmp from any to any
>> >
>> > [snip -- Some allowed ports (port 80, 443, etc.), and some denied IPs]
>> >
>> > # IRC (natd divert for IRC port-forwarding
>> > $IPF 50220 divert natd all from 72.20.28.202 6667 to 207.210.114.45 6667
via rl0
>>
>> The destination port must not be given (ie any destination port
>> corresponding to any source port greater than 1023 for the request) - in
>> this test the source port is 2897, in the next one it may be anything >
>> 1023. Moreover `any' in place of 207.210.114.45 would be nice to allow
>> others to chat. So the rule should be:
>>
>> $IPF 50220 divert natd all from 72.20.28.202 6667 to any via rl0
>>
>> Henri
>>
>>
>>
>> > $IPF 50221 divert natd all from any to 207.210.114.45 6667 via rl0
>> >
>> > Any attempt to connect to the IRC jail IP thus far, though, still
>> > fails with a "connection timed out."
>> >
>> > Thanks for your help thus far. Any additional ideas?
>> >
>> > On Mon, Mar 24, 2008 at 6:10 AM, Henri Hennebert <[EMAIL PROTECTED]>
wrote:
>> >> Kage wrote:
>> >> > Well, no, see it's hitting natd just fine as shown by my natd verbose
>> >> > logs, if you're assuming ipfw is blocking me from reaching natd. Are
>> >> > you talking about adding a firewall rule for each of my round-robin
>> >> > addresses, too?
>> >>
>> >> Yes
>> >>
>> >>
>> >> > How would that do any good?
>> >>
>> >> All response paquet to a paquet diverted to natd must also be diverted
>> >> to natd to be reverse translated. eg:
>> >>
>> >> incoming request from client (c) to server (s) redirected to server (S)
>> >>
>> >> c.c.c.c -> s.s.s.s nated as c.c.c.c -> S.S.S.S
>> >>
>> >> must have response paquetd reverse translated:
>> >>
>> >> S.S.S.S -> c.c.c.c nated as s.s.s.s -> c.c.c.c
>> >>
>> >> to be a valid response to client (c).
>> >>
>> >>
>> >>
>> >> >
>> >> > On Sat, Mar 22, 2008 at 9:27 AM, Henri Hennebert <[EMAIL PROTECTED]>
wrote:
>> >> >> Kage wrote:
>> >> >> > Hey guys,
>> >> >> >
>> >> >> >This is a fun one that's stumped people in Freenode ##freebsd.
>> >> >> > Basica
