Problem with lan to lan from Pix 501 and Vpnconcentrator behind a Checkpoint Firewall one (post #2)

Discussion in 'Cisco' started by Gianlu, Jul 2, 2004.

  1. Gianlu

    Gianlu Guest

    In my previous post I've made a mistake adding some rows regarding a
    previous posted question.

    The correct post is on the following rows.....

    Thanks in advice for your help!!!!

    Hi, I'm a newbye with the pix and after several work I have
    estabilished a vpn ipsec tunnel between a Pix501 on our remote office
    and vpnconcentrator on our main network.
    In details ur vpnconcentrator in the main office is putted in the DMZ
    behind a Checkpoint Firewall on.
    I've the following problem:
    We have configured a Lan to lan ipsec tunnel between the 2 networks
    configuring the pix for routing all the traffic going outside through
    the ipsec vpn so we can filter the traffic going towards internet from
    the remote office using our proxy and our checkpoint firewall
    centrally. So for example internet from the remote office is reached
    going into the tunnel, reaching the vpnconcentrator, entering in the
    checkpoint DMZ interface. Then checkpoint checks if the traffic is
    permitted or not and if permitted, sends it outside our network
    through our main internet connection (natted with a pubblic static ip
    by the checkpoint).
    Everythings works fine, but now on the remote office they asked to
    reach a public site using telnet with a non standard port (3048).
    I've configured the rules on our checkpoint to allow the traffic on
    that port from all our networks (included the remote side internal
    network) and I was waiting that it should works.
    Instead, while I can telnet on that port from our main network, from
    the remote network the telnet doesn't work.
    Logging the traffic on the firewall, I cannot see any packet coming
    from the ip address of the pc of our remote network trying to use the
    3048 port.

    I cannot understand why, if it is a problem on the pix, if I have to
    configure somethings on the vpnconcentrator or if is the network
    structure which do not permit the telnet on that port over a ipsec
    tunnel.

    Can someone help me please?

    Gianluigi

    Here is the Pix configuration with some ip changes:

    Building configuration...
    : Saved
    :
    PIX Version 6.3(3)
    interface ethernet0 auto
    interface ethernet1 100full
    nameif ethernet0 outside security0
    nameif ethernet1 inside security100
    enable password xxxxxxxxxxxxxxxx encrypted
    passwd xxxxxxxxxxxxxxx encrypted
    hostname Pix
    domain-name xxxxxxxxxxx
    fixup protocol dns maximum-length 512
    fixup protocol ftp 21
    fixup protocol h323 h225 1720
    fixup protocol h323 ras 1718-1719
    fixup protocol http 80
    fixup protocol rsh 514
    fixup protocol rtsp 554
    fixup protocol sip 5060
    fixup protocol sip udp 5060
    fixup protocol skinny 2000
    fixup protocol smtp 25
    fixup protocol sqlnet 1521
    fixup protocol tftp 69
    names
    name xxx.xxx.0.0 NetPrimary
    name 10.9.0.0 NetPix
    access-list inside_outbound_nat0_acl permit ip NetPix 255.255.0.0
    NetPrimary 255.255.0.0
    access-list outside_cryptomap_20 permit ip NetPix 255.255.0.0
    NetPrimary 255.255.0.0
    access-list outside_access_in permit ip NetPrimary 255.255.0.0 NetPix
    255.255.0.0
    pager lines 24
    logging on
    mtu outside 1500
    mtu inside 1500
    ip address outside yyy.yyy.yyy.yyy 255.255.255.248
    ip address inside 10.9.1.1 255.255.0.0
    ip audit info action alarm
    ip audit attack action alarm
    pdm logging informational 100
    pdm history enable
    arp timeout 14400
    nat (inside) 0 access-list inside_outbound_nat0_acl
    access-group outside_access_in in interface outside
    route outside 0.0.0.0 0.0.0.0 zzz.zzz.zzz.zzz 1 (comment:
    zzz.zzz.zzz.zzz is the ip address of the router towards internet)
    timeout xlate 0:05:00
    timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225
    1:00:00
    timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00
    timeout uauth 0:05:00 absolute
    aaa-server TACACS+ protocol tacacs+
    aaa-server RADIUS protocol radius
    aaa-server LOCAL protocol local
    http server enable
    http ???.???.???.??? 255.255.255.255 outside
    no snmp-server location
    no snmp-server contact
    snmp-server community public
    no snmp-server enable traps
    floodguard enable
    sysopt connection permit-ipsec
    crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac
    crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
    crypto map outside_map 20 ipsec-isakmp
    crypto map outside_map 20 match address outside_cryptomap_20
    crypto map outside_map 20 set peer nnn.nnn.nnn.nnn
    crypto map outside_map 20 set transform-set ESP-3DES-MD5
    crypto map outside_map interface outside
    isakmp enable outside
    isakmp key ******** address nnn.nnn.nnn.nnn netmask 255.255.255.255
    no-xauth no-config-mode
    isakmp nat-traversal 20
    isakmp policy 20 authentication pre-share
    isakmp policy 20 encryption 3des
    isakmp policy 20 hash md5
    isakmp policy 20 group 2
    isakmp policy 20 lifetime 86400
    telnet timeout 5
    ssh timeout 5
    console timeout 0
    terminal width 80
    Cryptochecksum:7e21083b04c2e47e80fa8f7c7de23a66
    : end [OK]
     
    Gianlu, Jul 2, 2004
    #1
    1. Advertisements

  2. :We have configured a Lan to lan ipsec tunnel between the 2 networks
    :configuring the pix for routing all the traffic going outside through
    :the ipsec vpn so we can filter the traffic going towards internet from
    :the remote office using our proxy and our checkpoint firewall
    :centrally.

    :Everythings works fine, but now on the remote office they asked to
    :reach a public site using telnet with a non standard port (3048).
    :I've configured the rules on our checkpoint to allow the traffic on
    :that port from all our networks (included the remote side internal
    :network) and I was waiting that it should works.
    :Instead, while I can telnet on that port from our main network, from
    :the remote network the telnet doesn't work.


    :pIX Version 6.3(3)

    :name xxx.xxx.0.0 NetPrimary
    :name 10.9.0.0 NetPix
    :access-list inside_outbound_nat0_acl permit ip NetPix 255.255.0.0 NetPrimary 255.255.0.0
    :access-list outside_cryptomap_20 permit ip NetPix 255.255.0.0 NetPrimary 255.255.0.0

    :nat (inside) 0 access-list inside_outbound_nat0_acl

    :route outside 0.0.0.0 0.0.0.0 zzz.zzz.zzz.zzz 1

    :crypto map outside_map 20 match address outside_cryptomap_20


    Your configuration does not send "all traffic going outside" through
    the IPSec tunnel. The configuration only sends the traffic matched
    by the access-list outside_cryptomap_20. That access-list in
    turn only matches if the IP address destination is in the NetPrimary
    IP address space. This means that the filtering you want to do
    will only take place if you are running a proxy service on each
    machine with the proxy set to go to a host in NetPrimary's IP range.

    Any traffic that does *not* happen to be destined for NetPrimary's IP range
    [e.g., because it is not matched by the proxy] will be dropped by
    the PIX with the way you have it configured at the moment. (In order for
    that traffic to -not- be dropped, you would have to have a nat/global
    pair, or use static's so that the PIX knew what outside IP to translate
    the inside traffic to.)

    The fact that you have this relayed filtering working at all suggests
    to me that you have configured the web browsers to use a proxy
    in NetPrimary's IP range. The browsers can usually be configured to
    proxy for http, https, and ftp (when used through the browser).
    The new telnet being requested on the odd port is probably not
    going through the web browser and so not going through the proxy
    you have [I deduce] established. If I am correct in my deduction,
    then you -might- be able to configure the browser to proxy
    the new port if the user puts in a telnet:// URL.


    The more general solution than trying to force everything through
    a browser proxy, would be to configure

    access-list inside_outbound_nat0_acl permit ip NetPix 255.255.0.0 any
    access-list outside_cryptomap_20 permit ip NetPix 255.255.0.0 any

    This would send -all- outgoing traffic through the IPSec tuhnel.
    No proxy configuration needed and any new traffic requirements
    would automatically get shunted to your checkpoint peer for
    filtering.


    If you do change the destination to 'any' then you will run into
    problems with any local infrastructure requests that shouldn't
    really being going through the filter checking. You don't
    *really* want everything to go through the Checkpoint, as you need
    to be able to ping (and possibly telnet to or snmp monitor) your
    router, and in turn your router might be sending you syslog
    reports. You probably want to leave enough exempted from the
    filtering to be able to traceroute to your Checkpoint peer
    so that you can debug network outages or slowdowns. As well as
    the usual icmp echo packets for ping, and the random high udp
    ports used by traceroute [but Windows tracert defaults to icmp],
    you will likely find that in practice to do the network debugging
    when the remote peer cannot be reached, that you will want your
    administration machine to be able to send out direct DNS requests
    and possibly 'name' (tcp 42) [used by 'whois'] and
    'rwhois' (tcp 4321) as well.

    A policy of "everything must be filtered through our central site"
    is nice in theory, but does not take into account the reality that
    when the link to the central site is broken or slow or malfunctioning,
    that you need to be able bypass the filter in order to figure out
    how to get the filter working again!
     
    Walter Roberson, Jul 3, 2004
    #2
    1. Advertisements

  3. Gianlu

    Gianlu Guest


    Hi,
    thanks for your answer....

    I made a mistake about our configuration. I've posted an old one.
    The correct configurations already send all the traffic through the
    ipsec with a vpn rule as below:


    access-list inside_outbound_nat0_acl permit ip 10.9.0.0 255.255.0.0
    any
    access-list outside_cryptomap_20 permit ip 10.9.0.0 255.255.0.0 any
    ..
    ..
    ip address outside x.x.x.x 255.255.255.248
    ip address inside 10.9.1.1 255.255.0.0
    ..
    ..
    nat (inside) 0 access-list inside_outbound_nat0_acl
    route outside 0.0.0.0 0.0.0.0 x.x.x.y 1
    ..
    ..
    sysopt connection permit-ipsec
    crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac
    crypto map outside_map 20 ipsec-isakmp
    crypto map outside_map 20 match address outside_cryptomap_20
    crypto map outside_map 20 set peer z.z.z.z
    crypto map outside_map 20 set transform-set ESP-3DES-MD5
    crypto map outside_map interface outside
    isakmp enable outside
    isakmp key ******** address z.z.z.z netmask 255.255.255.255 no-xauth
    no-config-mode
    isakmp policy 20 authentication pre-share
    isakmp policy 20 encryption 3des
    isakmp policy 20 hash md5
    isakmp policy 20 group 2
    isakmp policy 20 lifetime 86400


    So, keeping in mind your suggestions about not to tunnel all the
    traffic towards our primary office, the problem of seeing no packets
    starting from our remote network when I try to telnet the site on the
    port 3048 still remains.

    I cannot understand why.

    If I open a telnet session with the pix and I debug packets on the
    interface inside with as src the pc on the remote network who is doing
    the "telnet 193.110.28.164 3048" and destination the 193.110.28.164 I
    cannot see any packet beeing transmitted.

    Do someone knows why?

    Thanks in advice

    Gianluigi
     
    Gianlu, Jul 5, 2004
    #3
    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.