Comware

I'm trying to setup one-to-one NAT for both inbound and outbound for certain systems, specifically MX's. The inbound works but the outbound doesn't. The outbound takes the NAT address of the generic many-to-one outbound NAT. This is not a good situation since my mail servers do not pass a reverse lookup now that I've changed routers. I had this working on an old Intel router so I'm assuming it should work on the HP. I've attached the relevant portion of my config file.

This is really an issue now. My mail server logs are starting to show sites warning about us as possibly forged since my forward and reverse lookups no longer match due to the HP not setting the correct NAT address.

Dave,
that is not how you setup 1:1 NAT. See example below and read the documentation or use the wizard to configure 1:1 NAT.
Also, see attached file....
-------------------
Configuration:


hostname "ProCurveSR7102dl"
no enable password
!
!
ip subnet-zero
ip classless
ip routing
!
event-history on
no logging forwarding
no logging email
logging email priority-level info
!
no service password-encryption
!
!
ip firewall
no ip firewall alg h323
ip firewall alg sip udp 5060
!
!
no autosynch-mode
no safe-mode
!
!
!
interface eth 0/1
ip address 192.168.1.254 255.255.255.0
access-policy NATInside
no shutdown
!
interface eth 0/2
no ip address
shutdown
!
!
interface t1 1/1
tdm-group 1 timeslots 1-24 speed 64
no shutdown
!
interface t1 1/2
clock source through
shutdown
interface ppp 1
ip address 16.1.1.1 255.255.255.0
ip address 18.1.1.1 255.255.255.0 secondary
ip address 18.1.1.2 255.255.255.0 secondary
ip address 18.1.1.3 255.255.255.0 secondary
access-policy NATWeb
no shutdown
bind 1 t1 1/1 1 ppp 1
!
!
ip access-list standard Inside
permit any
!
!
ip access-list extended Web1
permit ip any host 18.1.1.1
!
ip access-list extended Web2
permit ip any host 18.1.1.2
!
ip access-list extended Web3
permit ip any host 18.1.1.3
!
ip policy-class NATInside
nat source list Inside interface ppp 1 overload
!
ip policy-class NATWeb
nat destination list Web1 address 192.168.1.1
nat destination list Web2 address 192.168.1.2
nat destination list Web3 address 192.168.1.3
!
!
!
ip route 0.0.0.0 0.0.0.0 16.1.1.2
!
no ip tftp server
no ip http server
no ip http secure-server
no ip snmp agent
no ip ftp agent
!
!
!
!
ip sip
ip sip proxy
!
line con 0
no login
!
line telnet 0 4
login
no shutdown
line ssh 0 4
login local-userlist
no shutdown
!
!
End

Olaf,

Your instructions are for Inbound one-to-one NAT and Outbound many-to-one NAT. I was looking for Outbound one-to-one NAT. I'll explain using your example of what I needed, why and what I did to resolve it.

In the example you give, Inbound traffic would go the following way:
18.1.1.1 -> 192.168.1.1
18.1.1.2 -> 192.168.1.2
18.1.1.3 -> 192.168.1.3

That's all well and good. The problem is with Outbound traffic. In your example, ALL Outbound traffic would be addressed with 16.1.1.1 as the source IP address. Not necessarily a bad thing unless you want to do a forwards and backwards match, as with an MX.

Let's assume 18.1.1.1 is a MX. And when you do a lookup of mx.mydomain.com you get 18.1.1.1 as the address. However, in your setup when mx.mydomain.com sends traffic outbound it has a source ip of 16.1.1.1. This causes problems with any kind of spam checking or identity verification type of process. You have a system that claims to be at one address yet seems to be sending from another.

So, for your example, I did the following.
First, create an access-list to select the Outbound traffic from the box we're interested in. Since the traffic is outbound, the source is the internal address.

ip access-list extended web1-nat
permit ip host 192.168.1.1 any log

Next, edit the NATInside policy-class to perform the NAT. The entry needs to come BEFORE the general outbound NAT and I found that even though it's only natt'ing 1 address, you need to add the overload statement or the command won't run.

ip policy-class NATInside
nat source list web1-nat address 18.1.1.1 overload
nat source list Inside interface ppp 1 overload

Now, outbound traffic from 192.168.1.1 will have a source address of 18.1.1.1 instead of 16.1.1.1 and will pass forward and backward lookup tests.

I hope that's a little clearer as to what I needed and why. If there's a better way to do this, I haven't found it yet.

Dave,

Thanks for the clarification. It makes sense now but the solution you found is the only one I know of. Are you just looking for a simpler/better solution? I am afraid you found the "best" one.

Olaf

Olaf,

I was looking for any solution. I had to replace an old Intel router with the HP for VPN, VLAN and H.323 compatibility. The Intel handled NAT a bit differently than the HP so I've had to find ways to accomplish what I was doing before. I think between having to add all my hosts (31) as secondaries on the ppp, I'm glad I only have a small Class C, and the outbound NAT trick, I think I'm back to running correctly.

The next thing is to tackle the VPN issue. I've got all the IKE and IPSec stuff working, meaning I can get the tunnel up and even ping the other end. However, beyond that it's pretty useless so far. I can't SEE any resources on the other side. I take that back, I've managed to fix it up so that my Novell resources show up across the VPN but not my MS resources or my Linux resources. The Novell was accomplished by putting up an SLPDA, service locater protocol directory agent. I'm trying to find something for MS and/or Linux but so far no luck. I just added the reverse-route to my transform set to see what that might do for me.

David,

VPN = unicast traffic only. MS uses broadcast for their service advertisement etc. You will never get those accross the VPN tunnel. You would have to create an L2TP tunnel, which the 7000dl router doesn't support. It only does IPSec VPN. What you might have to do is configure WINS servers and configure those on your clients (static or advertise them via DHCP). I am not sure how Linux advertises services.

Olaf

That's exactly what the SLP DA does for Novell. Once that was up, all my servers and services became available. I guess it's just another plus for Novell. I may have to see about extending my eDir to include my MS boxes. Maybe Novell can help MS work.