(I haven't entirely ruled out hardware problems, but it's very very unlikely).
Hi, I have a machine which managed to get a bizarre rule in the state table
today, (It has 6 interfaces, but only two of them have any affect on this.)
FreeBSD/IPF v3.4.27
if0: 192.168.0.0/24
if1: 217.206.128.227/27 and 217.206.130.227/26
Then the following nat rules:
map if1 from 192.168.193.0/24 to 217.206.128.224/27 -> 217.206.128.227/32
proxy port ftp ftp/tcp
map if1 from 192.168.193.0/24 port < 1024 to 217.206.128.224/27 ->
217.206.128.227/32 portmap tcp/udp 1:1023
map if1 from 192.168.193.0/24 to 217.206.128.224/27 -> 217.206.128.227/32
portmap tcp/udp auto
map if1 from 192.168.193.0/24 to 217.206.128.224/27 -> 217.206.128.227/32
map if1 192.168.193.0/24 -> 217.206.130.227/32 proxy port ftp ftp/tcp
map if1 192.168.193.0/24 -> 217.206.130.227/32 portmap tcp/udp auto
map if1 192.168.193.0/24 -> 217.206.130.227/32
The idea being that traffic for the 217.206.128.224/27 subnet is NAT'd to the
217.206.128.227 IP address, and traffic for anything else is routed via the
217.206.130.192/26 subnet to the internet.
For the most part this works, however this morning, we had a problem with
something getting into the state table, which just shouldn't have been there
MAP 192.168.0.206 <- -> 217.206.130.227 [217.206.128.226]
(this was for ping traffic, as far as I know).
It should have been:
MAP 192.168.0.206 <- -> 217.206.128.227 [217.206.128.226]
I just don't get how this could have managed to get into the state table with
the above ruleset.
Anyone else seen anything similar ?
-Antony
*************************************************************************
This e-mail and any attachments may contain confidential or privileged
information. If you are not the intended recipient, please contact the
sender immediately and do not use, store or disclose their contents.
Any views expressed are those of the individual sender and not of Kinetic
Information System Services Limited unless otherwise stated.
www.kinetic.co.uk
