new IOS NAT problem

Hi all,

I'm having some problems with the new IOS as I used to use the following NAT entry cos of having a range of IP's on the DSL connection and wanted to use the second one in the range for the SMTP

ip nat inside source static tcp 25 25 extendable

But now it doesn't work right any more cos the smtp server receives ok but when sending it comes out as the first one in the range, now I've found the following NAT but it seems to be for only the single ip and not a range.

ip nat inside source static tcp 25 interface dialer0 25

Any ideas on how I could get around this without redoing all my DNS for the mail server

Reply to
Loading thread data ...

If I understood well your issue is that you can reach your smtp from Internet by public IP derived from ip nat inside source static tcp 25 address> 25 extendable NAT rule, but when your SMTP is trying to communicate with Internet it's being translated onto an IP different then the one you defined in your static NAT entry? If so, then (if you implemented CBAC - IOS firewall) just make your static NAT entry into a more general one: ip nat inside source static - this will make your SMTP to communicate with Internet by all tcp/udp ports and to protect it only leave opened tcp 25 onto smtp host in inbound ACL on your Internet side router's interface. If you have also some dynamic NAT rules (for your local hosts being able to connect to Internet) make sure to exclude your smtp server from that rules (with deny statement in NAT access-lists).

If you need configuration help just let me know...

B.R. Igor

Reply to

ok here is the problem if i use

ip nat inside source static tcp 25 25 extendable

it ends up as .161 when the email server sends and if use

ip nat inside source static

then i can't see the server at from the other site on the private ip ie can't ping ip from can i do this so that i can still see it from site B on private range while the getting the smtp to still work.

here is the config...

crypto isakmp policy 20 encr 3des authentication pre-share group 2 crypto isakmp key sharedkey address ! ! crypto ipsec transform-set tr-esp-3des esp-3des esp-md5-hmac ! crypto map gateway 10 ipsec-isakmp set peer set transform-set tr-esp-3des match address 101 ! ! ! ! interface Ethernet0 ip address ip access-group 107 in ip nat inside ip tcp adjust-mss 1452 no ip mroute-cache hold-queue 100 out ! ! interface ATM0 no ip address ip nat outside no ip mroute-cache atm vc-per-vp 64 no atm ilmi-keepalive dsl operating-mode auto ! interface ATM0.1 point-to-point pvc 0/38 encapsulation aal5mux ppp dialer dialer pool-member 1 ! ! interface Dialer1 ip address ip mtu 1492 ip nat outside encapsulation ppp ip tcp adjust-mss 1452 dialer pool 1 dialer-group 1 ppp authentication chap callin ppp chap hostname ispusername ppp chap password isppassword crypto map gateway ! ip nat inside source route-map nonat interface Dialer1 overload

ip nat inside source static tcp 25 25 extendable ip classless ip route Dialer1 ! access-list 101 permit ip access-list 105 deny ip access-list 105 permit ip any access-list 107 permit ip any any log dialer-list 1 protocol ip permit route-map nonat permit 10 match ip address 105 ! !

Reply to

Have you tried playing round with the route-maps some more? I'm no in a position to test this right now, but does something like the following help:

! ip nat inside source route-map RM-NAT interface Dialer1 overload ip nat inside source static tcp 25 25 extendable ! ! Deny traffic for VPN access-list 101 permit ip ! Deny traffic to/from mail server access-list 102 permit ip host any ! permit rest of traffic going to the Internet access-list 103 permit ip any ! route-map RM-NAT deny 5 match ip address 101, 102 route-map RM-NAT permit 10 match ip address 103 !

Or maybe if you can use something like:

ip nat inside source static route-map RM-NoNAT route-map RM-NoNAT deny 5 match ip address 101 route-map RM-NoNAT permit 10 match ip address 102

I'd expect something along these lines to do the trick I think, the syntax may not be quite right as I have done it from memory but it should be close enough

Reply to
Al Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.