Is it so difficult to achieve?

Discussion in 'Cisco' started by AM, Jan 6, 2005.

  1. AM

    AM Guest

    I apologize if I repost questions about IPsec tunnels, but I don't realize I can not do what I want or, better, I can
    not easily do what I want.
    Anyhow I think I'm facing a common problem to all IPsec tunnel builders.

    The environment is

    2 LAN - say A=192.168.xxx.0/24 and B=172.21.yyy.0/27.
    PIX 525 on LAN A side.
    Netscreen on LAN B side (It doesn't matter IMHO)

    Each LAN belong to different companies.
    On LAN B there some clients having to access to web server on LAN A. The IP address assegnation of that server is a work
    in progress.
    The two networks' administrators wouldn't build tunnels ad hoc from LAN B to each possible IP address of the web server
    on LAN A. They want to build a tunnel from A LAN to LAN B.
    So even if LAN B administrator goes some days off, clients (say 172.21.xxx.5 and so on) must point their web browsers to
    new address instrad of the old ones. But they have to be able to point only to web servers LAN A's administrator
    decides. So access rules from LAN B to web server must change.
    The easiest way, IMHO, is to create a LAN to LAN IPsec tunnel and then apply further rules.But where?

    I built up, together with LAN B administrator, the tunnel protecting ip traffic from 192.168.xxx.0/24 to 172.21.yyy.0/27
    The rule applied

    access-list Tunn_E_Endpoint_cryptomap_12 permit ip 192.168.xxx.0 255.255.255.0 172.21.yyy.0 255.255.255.224

    works.
    Say I would shrink the ip traffic only to web server (192.168.xxx.45). The only way to achieve this I found out is to
    not protect all the traffic from and to 192.168.xxx.45. I did as follow:

    access-list Tunn_E_Endpoint_cryptomap_12 deny ip 192.168.xxx.0 255.255.255.224 172.21.yyy.0 255.255.255.224
    access-list Tunn_E_Endpoint_cryptomap_12 deny ip 192.168.xxx.32 255.255.255.248 172.21.yyy.0 255.255.255.224
    access-list Tunn_E_Endpoint_cryptomap_12 deny ip 192.168.xxx.40 255.255.255.252 172.21.yyy.0 255.255.255.224
    access-list Tunn_E_Endpoint_cryptomap_12 deny ip 192.168.xxx.44 255.255.255.255 172.21.yyy.0 255.255.255.224
    access-list Tunn_E_Endpoint_cryptomap_12 deny ip 192.168.xxx.46 255.255.255.254 172.21.yyy.0 255.255.255.224
    access-list Tunn_E_Endpoint_cryptomap_12 deny ip 192.168.xxx.48 255.255.255.240 172.21.yyy.0 255.255.255.224
    access-list Tunn_E_Endpoint_cryptomap_12 deny ip 192.168.xxx.64 255.255.255.192 172.21.yyy.0 255.255.255.224
    access-list Tunn_E_Endpoint_cryptomap_12 deny ip 192.168.xxx.128 255.255.255.128 172.21.yyy.0 255.255.255.224
    access-list Tunn_E_Endpoint_cryptomap_12 permit ip 192.168.xxx.0 255.255.255.0 172.21.yyy.0 255.255.255.224

    WHY can not I write something like this

    access-list Tunn_E_Endpoint_cryptomap_12 permit ip 192.168.xxx.45 255.255.255.255 172.21.yyy.0 255.255.255.224
    access-list Tunn_E_Endpoint_cryptomap_12 deny ip 192.168.xxx.0 255.255.255.0 172.21.yyy.0 255.255.255.224

    ??? (It don't works because PIX ( rel. 6.3(4) ) tells me there is no ACL for the tunnel)

    Have I to rewrite the above 8 access-list deny rules each time I change the target IP (the web server).
    Please, don't reply telling me a web server shouldn't change its IP address frequently. I posted an example.


    Any comment is really appreciated.

    Alex.
    AM, Jan 6, 2005
    #1
    1. Advertising

  2. In article <w4eDd.17994$H%>, AM <> wrote:
    :So access rules from LAN B to web server must change.
    :The easiest way, IMHO, is to create a LAN to LAN IPsec tunnel and then apply further rules.But where?

    Turn of sysopt connection permit-ipsec . Once that is off then:
    1) outgoing packets will be processed by the ACL applied to
    the inside interface, -before- they are candidates for being
    tunneled, and
    2) after a packet comes in through the tunnel and the pix has
    de-encapsulated it, the PIX will pass the packet through
    the ACL that is applied to the outside interface.

    Usually you would frame the tunnel crypto map at the 'ip' level
    or possibly 'tcp' or 'udp', and then you would adjust your
    interface ACLs to permit only the traffic that you actually
    want to cross the tunnel.

    What you cannot do is have some tcp (or udp) ports go through
    the tunnel and have the other ports between the same two systems
    go through normal public transmission.

    If your outside interface ACL is more restrictive than what the
    other end has configured, then the effect will be that some
    packets will make it through the tunnel from the remote end to
    your end, but will then be dropped by the PIX before being
    delivered to the inside.
    --
    'ignorandus (Latin): "deserving not to be known"'
    -- Journal of Self-Referentialism
    Walter Roberson, Jan 6, 2005
    #2
    1. Advertising

  3. AM

    AM Guest

    Walter Roberson wrote:
    > In article <w4eDd.17994$H%>, AM <> wrote:
    > :So access rules from LAN B to web server must change.
    > :The easiest way, IMHO, is to create a LAN to LAN IPsec tunnel and then apply further rules.But where?
    >
    > Turn of sysopt connection permit-ipsec . Once that is off then:
    > 1) outgoing packets will be processed by the ACL applied to
    > the inside interface, -before- they are candidates for being
    > tunneled, and
    > 2) after a packet comes in through the tunnel and the pix has
    > de-encapsulated it, the PIX will pass the packet through
    > the ACL that is applied to the outside interface.


    I think that "conditio sine qua non" is the creation of a static rule between LAN A and LAN B, isn't?
    But I have

    access-list inside_nat0_outbound permit ip object-group other_stuff host other_host
    access-list inside_nat0_outbound permit ip Other_name 255.255.255.0 host other_host2
    access-list inside_nat0_outbound permit ip object-group other_object other_LAN 255.255.255.0
    access-list inside_nat0_outbound permit ip 192.168.xxx.0 255.255.255.0 172.21.yyy.0 255.255.255.224

    and

    nat (inside) 0 access-list inside_nat0_outbound

    so, I must remove

    access-list inside_nat0_outbound permit ip 192.168.xxx.0 255.255.255.0 172.21.yyy.0 255.255.255.224

    and add a static(inside,Tunn_E_Endpoint) 172.21.yyy.0 255.255.255.224 172.21.yyy.0 255.255.255.224

    and finally I must create rule to apply to Tunn_E_Endpoint interface for the 172.21.yyy.0 to enter 192.168.xxx.0 with
    rules based on ports and protocol parameters

    Am I correct?

    > Usually you would frame the tunnel crypto map at the 'ip' level
    > or possibly 'tcp' or 'udp', and then you would adjust your
    > interface ACLs to permit only the traffic that you actually
    > want to cross the tunnel.
    >
    > What you cannot do is have some tcp (or udp) ports go through
    > the tunnel and have the other ports between the same two systems
    > go through normal public transmission.


    OK

    > If your outside interface ACL is more restrictive than what the
    > other end has configured, then the effect will be that some
    > packets will make it through the tunnel from the remote end to
    > your end, but will then be dropped by the PIX before being
    > delivered to the inside.

    OK

    Let me try.

    Thank you,
    Alex.
    AM, Jan 7, 2005
    #3
  4. In article <w4eDd.17994$H%>, AM <> wrote:
    [On a PIX]

    :WHY can not I write something like this

    :access-list Tunn_E_Endpoint_cryptomap_12 permit ip 192.168.xxx.45 255.255.255.255 172.21.yyy.0 255.255.255.224
    :access-list Tunn_E_Endpoint_cryptomap_12 deny ip 192.168.xxx.0 255.255.255.0 172.21.yyy.0 255.255.255.224

    ACLs have a default 'deny' at the end, so they will deny anything not
    permitted. Your proposed ACL would thus be equivilent to

    access-list Tunn_E_Endpoint_cryptomap_12 permit ip 192.168.xxx.45 255.255.255.255 172.21.yyy.0 255.255.255.224

    which is a perfectly valid ACL for a crypto map.

    [You'll find that the PIX prints this out as
    access-list Tunn_E_Endpoint_cryptomap_12 permit ip host 192.168.xxx.45 172.21.yyy.0 255.255.255.224
    ]

    If you tried that before and it didn't work, there might have been
    an inconsistancy in the ACLs between the two ends. When there is
    an inconsistancy in the ACLs, the actual Security Associations
    that result will usually be determined by which of the two systems
    initiated the tunnel. You can get some pretty odd behaviours.

    One thing to remember is that after you change the ACL for a
    crypto map, that it is best to clear the current security
    associations. If you don't, you will get some odd results as well,
    and in particular you are likely to end up with messages in the
    log about packets expecting to be protected that weren't,
    or that weren't expected to be protected but were protected.


    But if I understand correctly, part of your difficulty is that
    the two LAN administrators are -not- acting in synchronization
    (e.g., you mentioned that one of the two might be away.) If that
    is the case, then if you change the crypto map ACL on your end,
    are are going to end up with inconsistancies until the other
    person returns and catches up. That's why it's better in such
    situations to have the tunnel willing to carry the traffic
    for all the possibilities, but to turn off the sysopt connection
    permit-ipsec and use interface ACLs to control what is really
    allowed into or out of the tunnel.
    --
    When your posts are all alone / and a user's on the phone/
    there's one place to check -- / Upstream!
    When you're in a hurry / and propagation is a worry/
    there's a place you can post -- / Upstream!
    Walter Roberson, Jan 7, 2005
    #4
  5. In article <8nsDd.18447$>, AM <> wrote:

    :I think that "conditio sine qua non" is the creation of a static rule between LAN A and LAN B, isn't?

    No, when you have nat 0 access-list then you do not need a 'static'.
    It's one of the important side-effects of the command.

    :so, I must remove

    :access-list inside_nat0_outbound permit ip 192.168.xxx.0 255.255.255.0 172.21.yyy.0 255.255.255.224

    :and add a static(inside,Tunn_E_Endpoint) 172.21.yyy.0 255.255.255.224 172.21.yyy.0 255.255.255.224

    So far you have been describing only a PIX with two interfaces,
    inside and outside. You cannot create an interface by using
    a 'static' command, and VPN tunnels are NOT allocated virtual endpoints.
    You also cannot rename the outside interface. Therefore, the
    above command would only be valid if you had a third interface
    which you were terminating the tunnel on instead of the outside
    interface.
    --
    Suppose there was a test you could take that would report whether
    you had Free Will or were Pre-Destined. Would you take the test?
    Walter Roberson, Jan 7, 2005
    #5
  6. AM

    AM Guest

    Walter Roberson wrote:
    > In article <8nsDd.18447$>, AM <> wrote:
    >
    > :I think that "conditio sine qua non" is the creation of a static rule between LAN A and LAN B, isn't?
    >
    > No, when you have nat 0 access-list then you do not need a 'static'.
    > It's one of the important side-effects of the command.
    >
    > :so, I must remove
    >
    > :access-list inside_nat0_outbound permit ip 192.168.xxx.0 255.255.255.0 172.21.yyy.0 255.255.255.224
    >
    > :and add a static(inside,Tunn_E_Endpoint) 172.21.yyy.0 255.255.255.224 172.21.yyy.0 255.255.255.224
    >
    > So far you have been describing only a PIX with two interfaces,
    > inside and outside. You cannot create an interface by using
    > a 'static' command, and VPN tunnels are NOT allocated virtual endpoints.
    > You also cannot rename the outside interface. Therefore, the
    > above command would only be valid if you had a third interface
    > which you were terminating the tunnel on instead of the outside
    > interface.


    I apologize for lacking informations. Our PIX has 5 interfaces. Two of them are "inside" and "Tunn_E_endpoint". We
    terminate the IPsec tunnels on the Tunn_E_endpoint interfaces.

    Anyway I was wrong by writing

    static(inside,Tunn_E_Endpoint) 172.21.yyy.0 255.255.255.224 172.21.yyy.0 255.255.255.224

    I have to map the net 192.168.xxx.0 on the Tunn_E_Endpoint. So the correct input, I think, is

    static(inside,Tunn_E_Endpoint) 192.168.xxx.0 255.255.255.0 192.168.xxx.0 255.255.255.0

    Having only the inside and the outside interfaces I should map 192.168.xxx.0 on the outside interface (is it quite
    dangerous without careful definitions of ACLs). I think this why my collegues added a specific interface to which
    temninate the tunnels.

    Thank you very much for your support,
    Alex.
    AM, Jan 7, 2005
    #6
  7. AM

    AM Guest

    Walter Roberson wrote:

    > In article <w4eDd.17994$H%>, AM <> wrote:
    > [On a PIX]
    >
    > :WHY can not I write something like this
    >
    > :access-list Tunn_E_Endpoint_cryptomap_12 permit ip 192.168.xxx.45 255.255.255.255 172.21.yyy.0 255.255.255.224
    > :access-list Tunn_E_Endpoint_cryptomap_12 deny ip 192.168.xxx.0 255.255.255.0 172.21.yyy.0 255.255.255.224
    >
    > ACLs have a default 'deny' at the end, so they will deny anything not
    > permitted. Your proposed ACL would thus be equivilent to
    >
    > access-list Tunn_E_Endpoint_cryptomap_12 permit ip 192.168.xxx.45 255.255.255.255 172.21.yyy.0 255.255.255.224
    >
    > which is a perfectly valid ACL for a crypto map.
    >
    > [You'll find that the PIX prints this out as
    > access-list Tunn_E_Endpoint_cryptomap_12 permit ip host 192.168.xxx.45 172.21.yyy.0 255.255.255.224
    > ]
    >
    > If you tried that before and it didn't work, there might have been
    > an inconsistancy in the ACLs between the two ends. When there is
    > an inconsistancy in the ACLs, the actual Security Associations
    > that result will usually be determined by which of the two systems
    > initiated the tunnel. You can get some pretty odd behaviours.
    > One thing to remember is that after you change the ACL for a
    > crypto map, that it is best to clear the current security
    > associations. If you don't, you will get some odd results as well,
    > and in particular you are likely to end up with messages in the
    > log about packets expecting to be protected that weren't,
    > or that weren't expected to be protected but were protected.


    How can I clear SA?

    > But if I understand correctly, part of your difficulty is that
    > the two LAN administrators are -not- acting in synchronization
    > (e.g., you mentioned that one of the two might be away.) If that
    > is the case, then if you change the crypto map ACL on your end,
    > are are going to end up with inconsistancies until the other
    > person returns and catches up. That's why it's better in such
    > situations to have the tunnel willing to carry the traffic
    > for all the possibilities, but to turn off the sysopt connection
    > permit-ipsec and use interface ACLs to control what is really
    > allowed into or out of the tunnel.


    Yes, yes, this is what I meant!

    Alex.
    AM, Jan 7, 2005
    #7
  8. In article <OpuDd.18602$>, AM <> wrote:
    :How can I clear SA?

    clear crypto sa while in 'configure terminal' mode

    You can also a peer address or a map name, or even an
    individual SA

    usage: clear crypto [ipsec] sa { peer <addr> |map <name> | counters |
    entry <addr> <prot> <spi>

    --
    WW{Backus,Church,Dijkstra,Knuth,Hollerith,Turing,vonNeumann}D ?
    Walter Roberson, Jan 7, 2005
    #8
  9. AM

    AM Guest

    Walter Roberson wrote:

    OK! It finally works!

    > In article <w4eDd.17994$H%>, AM <> wrote:
    > :So access rules from LAN B to web server must change.
    > :The easiest way, IMHO, is to create a LAN to LAN IPsec tunnel and then apply further rules.But where?
    >
    > Turn of sysopt connection permit-ipsec . Once that is off then:


    done

    > 1) outgoing packets will be processed by the ACL applied to
    > the inside interface, -before- they are candidates for being
    > tunneled, and


    OK I have an IP traffic allow from the inside to the other interfaces

    > 2) after a packet comes in through the tunnel and the pix has
    > de-encapsulated it, the PIX will pass the packet through
    > the ACL that is applied to the outside interface.


    OK

    >
    > Usually you would frame the tunnel crypto map at the 'ip' level
    > or possibly 'tcp' or 'udp', and then you would adjust your
    > interface ACLs to permit only the traffic that you actually
    > want to cross the tunnel.


    Yes it is what I have tried to do for 1 month

    > What you cannot do is have some tcp (or udp) ports go through
    > the tunnel and have the other ports between the same two systems
    > go through normal public transmission.


    Yes, all traffic must travel along the tunnel and stopped or allowed at the ends of the tunnel.
    Obviously it is better stopping traffic before traveling the tunnel to save bandwidth...

    > If your outside interface ACL is more restrictive than what the
    > other end has configured, then the effect will be that some
    > packets will make it through the tunnel from the remote end to
    > your end, but will then be dropped by the PIX before being
    > delivered to the inside.


    I had to map the inside network on Tunn_E_Endpoint

    -- static (inside,Tunn_E_Endpoint) 192.168.31.0 255.255.255.0 192.168.31.0 255.255.255.0 --

    (my colleagues hadn't it, so it was basically for the target to be reached)

    and then I had to apply the ACL.

    Alex.
    AM, Jan 8, 2005
    #9
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Anton

    How to Achieve Wireless Security?

    Anton, Oct 19, 2004, in forum: Wireless Networking
    Replies:
    7
    Views:
    762
    Carey Holzman
    Nov 10, 2004
  2. John Rennie
    Replies:
    4
    Views:
    1,225
    John Rennie
    Aug 26, 2005
  3. Jimchip
    Replies:
    2
    Views:
    542
    Paul - xxx
    Jul 19, 2003
  4. TX20

    How do you achieve this portrait effect???

    TX20, Oct 9, 2003, in forum: Digital Photography
    Replies:
    4
    Views:
    377
  5. Robert Feinman

    Somethings yet for digital to achieve

    Robert Feinman, Jun 19, 2004, in forum: Digital Photography
    Replies:
    0
    Views:
    316
    Robert Feinman
    Jun 19, 2004
Loading...

Share This Page