how to open ports for mail server on a 2621 router

Discussion in 'Cisco' started by Alexis Crawford, Apr 2, 2004.

  1. Hello,

    We are commissionning an Exchange server friday. The server will be
    located behind our router. It will have a private ip address. I must
    configure the router to let pop and smtp through to our internal
    network. Emails must come go in and go out of our network. VPN is set up
    on the router and i am afraid to make configuration changes that may
    affect VPN connectivity. Would someone please take a look at the
    configuration below and let me know what other configuration lines i
    must put to bring the exchange server online. I will be using the ip
    206.47.215.138 and forward it to an internal ip address.

    Building configuration...

    Current configuration : 3394 bytes
    !
    version 12.2
    service config
    service timestamps debug uptime
    service timestamps log uptime
    no service password-encryption
    !
    hostname CanHQ
    !
    enable secret 5 $1$pUG8$bWepiWs004BCwq5HTmKfT1
    enable password password1
    !

    aaa new-model
    !
    !
    aaa authentication login userauthen local
    aaa authorization network groupauthor local
    aaa session-id common
    ip subnet-zero
    no ip source-route
    !
    !
    ip domain name canfornav
    ip name-server 198.235.216.131
    ip name-server 198.235.216.130
    no ip dhcp conflict logging
    !
    !
    crypto isakmp policy 1
    encr 3des
    hash md5
    authentication pre-share
    group 2
    !
    crypto isakmp client configuration group ghyuuuuuuuuu
    key fffffffff6ty
    dns 198.235.216.131
    wins 192.168.1.113
    domain canfornav
    pool ourpool
    acl 101
    !
    !
    crypto ipsec transform-set STRONG esp-des esp-md5-hmac
    !
    crypto dynamic-map dynmap 10
    set transform-set STRONG
    !
    !
    crypto map Cryptomap client authentication list userauthen
    crypto map Cryptomap isakmp authorization list groupauthor
    crypto map Cryptomap client configuration address initiate
    crypto map Cryptomap client configuration address respond
    crypto map Cryptomap 10 ipsec-isakmp dynamic dynmap
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    mta receive maximum-recipients 0
    !
    !
    !
    !
    interface Loopback0
    ip address 1.1.1.1 255.255.255.0
    !
    interface FastEthernet0/0
    description connected to service provider's router
    ip address 206.47.215.138 255.255.255.248
    ip nat outside
    no ip route-cache
    no ip mroute-cache
    speed 10
    full-duplex
    crypto map Cryptomap
    !
    interface FastEthernet0/1
    description connected to lan
    ip address 192.168.1.254 255.255.255.0
    ip nat inside
    no ip route-cache
    no ip mroute-cache
    ip policy route-map nonat
    duplex auto
    speed auto
    !
    ip local pool ourpool 10.1.1.1 10.1.1.254
    ip nat inside source list 103 interface FastEthernet0/0 overload
    ip classless
    ip route 0.0.0.0 0.0.0.0 206.47.215.137
    no ip http server
    ip pim bidir-enable
    !
    !
    ip access-list extended addr-pool
    ip access-list extended default-domain
    ip access-list extended idletime
    ip access-list extended key-exchange
    ip access-list extended service
    ip access-list extended timeout
    ip access-list extended wins-servers
    !
    access-list 101 permit ip 192.168.1.0 0.0.0.255 10.1.1.0 0.0.0.255
    access-list 102 permit ip 192.168.1.0 0.0.0.255 10.1.1.0 0.0.0.255
    access-list 103 deny ip 192.168.1.0 0.0.0.255 10.1.1.0 0.0.0.255
    access-list 103 permit ip 192.168.1.0 0.0.0.255 any
    dialer-list 1 protocol ip permit
    dialer-list 1 protocol ipx permit
    !
    route-map nonat permit 10
    match ip address 102
    set ip next-hop 1.1.1.2
    !
    radius-server authorization permit missing Service-Type
    call rsvp-sync
    !
    !
    mgcp profile default
    !
    !
    !
    dial-peer cor custom
    !
    !
    !
    !
    !
    line con 0
    exec-timeout 0 0
    password xxxxxxxxxxxx
    line aux 0
    line vty 0 4
    exec-timeout 5 0
    password ggggghyujuuu
    !
    !
    end
     
    Alexis Crawford, Apr 2, 2004
    #1
    1. Advertisements

  2. :We are commissionning an Exchange server friday. The server will be
    :located behind our router. It will have a private ip address. I must
    :configure the router to let pop and smtp through to our internal
    :network. Emails must come go in and go out of our network. VPN is set up
    :in the router

    Is this Exchange 2003 with Active Directory, or an older Exchange
    with NETBIOS?

    I have not had the joy of working with an AD setup, so I cannot
    comment on that case.

    If, though, you are working with Exchange with NETBIOS, you must be
    careful in a remote peer situation, or in any situation in which remote
    locations must access the Exchange server functions directly [not just
    SMTP + pop -- neither of which can, for exammple, provide access to
    shared address books or shared calendars] Exchange with NETBIOS
    relies heavily on NT login protocols and on transfering data
    between PDCs using NETBIOS datagrams.... and those functions don't
    work quite right if you have the Exchange server on a private IP
    address. And for that matter, Exchange server will not always
    talk to its clients properly if they are NAT'd relative to the
    Exchange server.

    When Exchange + NETBIOS communicates through NETBIOS packets, it
    will send its *private* IP adddress (because it doesn't know it's
    public iP at the NETBIOS level]. Any system that is learning that
    address through NETBIOS based protocols (e.g., WINS rather than
    through a solid LMHOSTS hardcoding) is going to learn the private
    IP, and is going to try to send packets to that private IP.
    The VPN you show in your configuration is not set up to allow those
    private IPs to flow through directly -- so when your hosts in the
    remote locations learn the 192.168.x.x IP being carried in the
    NETBIOS packets [which is too deep to be NAT'd in transmission],
    they are going try to send -locally- to that IP to try to reach the
    NETBIOS server.

    The problem happens in reverse too: the Exchange server learns the
    private (10.*.*.*) IP addresses of its clients through NETBIOS, and
    then on occasions when it wants to send something to them [e.g.,
    a notification of new email] then it is going to try to send directly
    to that private IP, rather than to the NAT'd IP that is needed to get
    through. And even if it didn't mess this up (and it doesn't -always-),
    if the NAT'd IPs are not static relative to the Exchange server and
    client, then it's going to send to the NAT'd IP it has on record -- which
    might have been four or 50 address pool clients ago, as Exchange is
    known to hold on to the IP address for 2 or more weeks. And nevermind
    the fact that the firewall in the middle had negotiated flow of that
    port only temporarily, for a limited time: Exchange server (NETBIOS
    version anyhow) has no concept that port numbers might be very transcient,
    and it will try and try and try and retry to get through to that port
    number that it once used :(


    So... if you plan to install an Exchange server (pre-AD at least) and
    you plan remote Exchange peers or direct remote clients, then if you
    want Exchange to work properly, you must essentially turn off all
    address translation between all the devices concerned, and you must set
    any firewall to leave ports open for a *minimum* of two weeks. And
    even if you do all of that, you will see weird cases show up from
    time to time.


    The lesson should be clear: Exchhange that talks NETBIOS to its clients
    is (IMHO) incompatable with meaningful compartimentalization and
    seccurity. If your geographically-dispersed organization places a high
    value on security, then Exchange with NETBIOS is [IMHO] not the
    right mail server for your organization. But if you are allowed
    to force all interactions with Exchange to be SMTP / IMAP4S
    [including for clients on the same LAN] and all the advanced
    conveniences of Exchange can go hang, thn it shouldn't be any
    worse than any other isolated mail server. [Unless, that is,
    you care about backups and ability to recover individual messages
    without rebuilding the entire index for the entire message store.
    Some people are fussy about tinsy little issues like that...]


    I read between the lines in your posting that the Exchange server
    was decided upon by a level much higher than is likely to care about
    how you have to configure your router to accomedate it?
     
    Walter Roberson, Apr 2, 2004
    #2
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.