On 08.05.2004 00:42 +0300, J. James wrote:

> I have a static WAN IP  xx.xx.xx.194/29. So far so good. Now I want
> to add  another IP xx.xx.xx.195, so I added NAT -> Server NAT ->
> External IP  xx.xx.xx.195. Then I try to Diagnostics/Ping and
> xx.xx.xx.194 pings but  xx.xx.xx.195 doesn't.

That's OK...

> OK - the next step: Manuel states 
> (http://m0n0.ch/wall/list/?action=show_msg&actionargs[]=7&actionarg
> s[]=79)  "No, you don't have to bind those addresses to your WAN
> interface. Just  use 1:1 NAT, it somehow just works. Call it magic.
> ;) No, seriously -  m0n0wall automatically binds 1:1 NATed WAN IPs
> to its WAN interface."

That was a long time ago and is no longer true. No IP aliasing on WAN
is done anymore because it simply doesn't scale well (what with
people who need m0n0wall to answer ARP requests for a whole /24
subnet), and people with real routed subnets or PPPoE/PPTP don't need
it. The answer is proxy ARP, which means that m0n0wall will answer
ARP requests on WAN for all the IP addresses that you specify,
causing the upstream router to send packets destined to those IP
addresses to m0n0wall, which can then redirect them to the desired
destination with NAT. Since proxy ARP IP addresses are not really
bound to the WAN interface (no IP aliases), it won't answer ICMP echo
requests on them.

> So... The next step is to delete Server NAT and to try NAT -> 1:1
> ->  External Subnet -> xx.xx.xx.195/32 and internal subnet
> yy.yy.yy.11. The  situation is the same: xx.xx.xx.194 pings -
> xx.xx.xx.195 doesn't.

Again - you can't use ping to test here. Adding a proxy ARP entry for
the additional IP address and either 1:1 or Server NAT entries, and
of course filter rules, should be all it takes. Just remember that
you need to test from WAN; you can't access NATed services on any of
the WAN IP addresses from LAN (for reasons explained about 1001 times
on this list). If it still doesn't work, you'll have to use a packet
sniffer to find out what's going wrong.

- Manuel