remove sysopt connection permit-ipsec on my PIX?

Discussion in 'Cisco' started by You May Know Who, Nov 4, 2004.

  1. Here is the issue: I have an access list for the vpn clients and it
    currently allows "IP" to specific hosts. I would like to refine this so that
    only specific ports on these hosts are available. When I change the access
    list to only the ports it doesn't work. After going around and around TAC
    finally comes back and says if I remove "sysopt connection permit-ipsec and
    create access-lists and an access-group for the outside interface, but I
    don't recommend this very much."

    Can someone explain why?
     
    You May Know Who, Nov 4, 2004
    #1
    1. Advertising

  2. In article <Jvyid.4733$>,
    You May Know Who <> wrote:
    :Here is the issue: I have an access list for the vpn clients and it
    :currently allows "IP" to specific hosts. I would like to refine this so that
    :eek:nly specific ports on these hosts are available. When I change the access
    :list to only the ports it doesn't work.

    I may be mixing up various pieces of documentation (I go through
    too much interrelated documents to keep everything straight in one reading)
    but as I recall, PIX 6.3(4) is just starting to support negotiating port
    lists. Earlier versions didn't allow it at all -- the port numbers would be
    ignored in the ACL used to 'match address'. [It might have been
    the release notes on the VPN client that I was reading, with support
    not there yet at all on the PIX.]


    :After going around and around TAC
    :finally comes back and says if I remove "sysopt connection permit-ipsec and
    :create access-lists and an access-group for the outside interface, but I
    :don't recommend this very much."

    :Can someone explain why?

    I can't explain why the TAC would say they didn't recommend that
    approach, but I can point out one factor:

    When you have 'ip' permitted in the 'match address' ACL, then all
    traffic that matches that ACL will be permitted over the link. When
    the traffic hits your outside PIX interface and if you do *not* have
    the sysopt in place, then if the packet is not permitted by the ACL on
    the outside interface, the packet will be dropped. This has the effect
    of restricting access to only specific ports, which is the end you
    want. It does mean, though, that if the user -tries- to send other
    traffic that matches on IP, that the traffic will make it all the way
    to your PIX before getting dropped, which might mean that the remote
    user is paying for a bunch of traffic that isn't getting to the final
    destination. It would thus be better if the undesired traffic never
    went over the link at all, which would be the effect if the PIX knew
    how to send port number lists to the VPN client [which is allowed in
    IPSec, but it's pretty much the first optional feature after a long
    list of mandatory features.]

    The flip side of this is that if you are using split horizons
    and a specific list of ports, then all traffic that doesn't match those
    ports will be allowed to go out on the regular network. So if you
    had (say) permit tcp any host 172.16.1.1 eq www
    then if the user tried to send any other traffic to 172.16.1.1 the
    traffic would head out of their LAN interface, to be dropped at the
    far side of the ISP's network when it figures out it doesn't know
    how to route anything to 172.16.*.*. And if you just happen to be
    using public IP space internally that doesn't belong to you, then
    the traffic would end up at the 'real' destination instead of at your
    internal network.


    Keeping these in mind, I would say that it is much better for the
    PIX administrator to go without the sysopt and to keep strict ACLs:
    that way you avoid surprises such as the user's PC infecting all
    of your internal systems with a virus because you trusted all traffic
    from the user's PC.
    --
    I predict that you will not trust this prediction.
     
    Walter Roberson, Nov 4, 2004
    #2
    1. Advertising

  3. You May Know Who

    juniperr Guest

    You could have just left everything the same and used an inside
    interface ACL that blocked all the PCs from communicating back to the
    IPSEC tunnel except to that port.


    -cnrc.gc.ca (Walter Roberson) wrote in message news:<cmeee8$2uu$>...
    > In article <Jvyid.4733$>,
    > You May Know Who <> wrote:
    > :Here is the issue: I have an access list for the vpn clients and it
    > :currently allows "IP" to specific hosts. I would like to refine this so that
    > :eek:nly specific ports on these hosts are available. When I change the access
    > :list to only the ports it doesn't work.
    >
    > I may be mixing up various pieces of documentation (I go through
    > too much interrelated documents to keep everything straight in one reading)
    > but as I recall, PIX 6.3(4) is just starting to support negotiating port
    > lists. Earlier versions didn't allow it at all -- the port numbers would be
    > ignored in the ACL used to 'match address'. [It might have been
    > the release notes on the VPN client that I was reading, with support
    > not there yet at all on the PIX.]
    >
    >
    > :After going around and around TAC
    > :finally comes back and says if I remove "sysopt connection permit-ipsec and
    > :create access-lists and an access-group for the outside interface, but I
    > :don't recommend this very much."
    >
    > :Can someone explain why?
    >
    > I can't explain why the TAC would say they didn't recommend that
    > approach, but I can point out one factor:
    >
    > When you have 'ip' permitted in the 'match address' ACL, then all
    > traffic that matches that ACL will be permitted over the link. When
    > the traffic hits your outside PIX interface and if you do *not* have
    > the sysopt in place, then if the packet is not permitted by the ACL on
    > the outside interface, the packet will be dropped. This has the effect
    > of restricting access to only specific ports, which is the end you
    > want. It does mean, though, that if the user -tries- to send other
    > traffic that matches on IP, that the traffic will make it all the way
    > to your PIX before getting dropped, which might mean that the remote
    > user is paying for a bunch of traffic that isn't getting to the final
    > destination. It would thus be better if the undesired traffic never
    > went over the link at all, which would be the effect if the PIX knew
    > how to send port number lists to the VPN client [which is allowed in
    > IPSec, but it's pretty much the first optional feature after a long
    > list of mandatory features.]
    >
    > The flip side of this is that if you are using split horizons
    > and a specific list of ports, then all traffic that doesn't match those
    > ports will be allowed to go out on the regular network. So if you
    > had (say) permit tcp any host 172.16.1.1 eq www
    > then if the user tried to send any other traffic to 172.16.1.1 the
    > traffic would head out of their LAN interface, to be dropped at the
    > far side of the ISP's network when it figures out it doesn't know
    > how to route anything to 172.16.*.*. And if you just happen to be
    > using public IP space internally that doesn't belong to you, then
    > the traffic would end up at the 'real' destination instead of at your
    > internal network.
    >
    >
    > Keeping these in mind, I would say that it is much better for the
    > PIX administrator to go without the sysopt and to keep strict ACLs:
    > that way you avoid surprises such as the user's PC infecting all
    > of your internal systems with a virus because you trusted all traffic
    > from the user's PC.
     
    juniperr, Nov 5, 2004
    #3
  4. In article <>,
    juniperr <> wrote:
    :You could have just left everything the same and used an inside
    :interface ACL that blocked all the PCs from communicating back to the
    :IPSEC tunnel except to that port.

    No, that would not work, for three reasons:

    1) If you do not remove the sysopt connection permit-ipsec,
    then the inside interface ACL is skipped for VPN traffic; if you
    do remove the sysopt connection permit-ipsec then you have to
    configure the outside ACL anyhow.

    2) The PIX Adaptive Security Algorithm works even on VPN traffic, so if
    the remote PC initiated a connection to (say) port 1433 and that was
    permitted by either sysopt permit-ipsec or by the outside interface
    ACL, then the PIX would add a temporary entry internally
    into the beginning of the inside-interface ACL that permitted the
    return traffic. That entry placed by the PIX is going to be processed
    before any of the inside interface ACL entries, and so even if you
    explicitly blocked the return traffic, the access would be permitted
    before you got to the deny statement;

    3) Remember, the PC is usually going to be using a dynamic port,
    so you would have to code the inside refusal in the form

    access-list Inside2Out deny tcp any eq PORT-TO-REFUSE any

    but you would have to do that carefully in order to permit out
    the traffic you -do- want to be able to reach that port [just not to
    be able to reach it from the VPN.] And if PORT-TO-REFUSE is above
    1023 you run the risk that an inside host randomly picked that port
    when it tried to go outwards (e.g., to look at a web page.)
    Sure, a system acting as a server with respect to that port won't
    generate it on outgoing traffic, but any other machine that doesn't
    have a server on that port might pick it.
    --
    This signature intentionally left... Oh, darn!
     
    Walter Roberson, Nov 5, 2004
    #4
  5. You May Know Who

    PES Guest

    juniperr wrote:
    > You could have just left everything the same and used an inside
    > interface ACL that blocked all the PCs from communicating back to the
    > IPSEC tunnel except to that port.
    >

    Not on a pix. On a router maybe, but it would not protect your network
    from one way udp traffic. On a router, you could use an outboung acl on
    the inside interface to achieve this, but no on the pix.

    >
    > -cnrc.gc.ca (Walter Roberson) wrote in message news:<cmeee8$2uu$>...
    >
    >>In article <Jvyid.4733$>,
    >>You May Know Who <> wrote:
    >>:Here is the issue: I have an access list for the vpn clients and it
    >>:currently allows "IP" to specific hosts. I would like to refine this so that
    >>:eek:nly specific ports on these hosts are available. When I change the access
    >>:list to only the ports it doesn't work.
    >>
    >>I may be mixing up various pieces of documentation (I go through
    >>too much interrelated documents to keep everything straight in one reading)
    >>but as I recall, PIX 6.3(4) is just starting to support negotiating port
    >>lists. Earlier versions didn't allow it at all -- the port numbers would be
    >>ignored in the ACL used to 'match address'. [It might have been
    >>the release notes on the VPN client that I was reading, with support
    >>not there yet at all on the PIX.]
    >>
    >>
    >>:After going around and around TAC
    >>:finally comes back and says if I remove "sysopt connection permit-ipsec and
    >>:create access-lists and an access-group for the outside interface, but I
    >>:don't recommend this very much."
    >>
    >>:Can someone explain why?
    >>
    >>I can't explain why the TAC would say they didn't recommend that
    >>approach, but I can point out one factor:
    >>
    >>When you have 'ip' permitted in the 'match address' ACL, then all
    >>traffic that matches that ACL will be permitted over the link. When
    >>the traffic hits your outside PIX interface and if you do *not* have
    >>the sysopt in place, then if the packet is not permitted by the ACL on
    >>the outside interface, the packet will be dropped. This has the effect
    >>of restricting access to only specific ports, which is the end you
    >>want. It does mean, though, that if the user -tries- to send other
    >>traffic that matches on IP, that the traffic will make it all the way
    >>to your PIX before getting dropped, which might mean that the remote
    >>user is paying for a bunch of traffic that isn't getting to the final
    >>destination. It would thus be better if the undesired traffic never
    >>went over the link at all, which would be the effect if the PIX knew
    >>how to send port number lists to the VPN client [which is allowed in
    >>IPSec, but it's pretty much the first optional feature after a long
    >>list of mandatory features.]
    >>
    >>The flip side of this is that if you are using split horizons
    >>and a specific list of ports, then all traffic that doesn't match those
    >>ports will be allowed to go out on the regular network. So if you
    >>had (say) permit tcp any host 172.16.1.1 eq www
    >>then if the user tried to send any other traffic to 172.16.1.1 the
    >>traffic would head out of their LAN interface, to be dropped at the
    >>far side of the ISP's network when it figures out it doesn't know
    >>how to route anything to 172.16.*.*. And if you just happen to be
    >>using public IP space internally that doesn't belong to you, then
    >>the traffic would end up at the 'real' destination instead of at your
    >>internal network.
    >>
    >>
    >>Keeping these in mind, I would say that it is much better for the
    >>PIX administrator to go without the sysopt and to keep strict ACLs:
    >>that way you avoid surprises such as the user's PC infecting all
    >>of your internal systems with a virus because you trusted all traffic
    >>from the user's PC.
     
    PES, Nov 6, 2004
    #5
  6. You May Know Who

    wr Guest

    Its way too hard to define these extra acl's == you will probably mess
    up and create security holes. You are better off allowing the pix to
    dynamically create these. Also, it is more secure because it is
    similar to packet inspection, where only required acl's are created,
    not broad range acl's that stay open all the time.

    "You May Know Who" <> wrote in message news:<Jvyid.4733$>...
    > Here is the issue: I have an access list for the vpn clients and it
    > currently allows "IP" to specific hosts. I would like to refine this so that
    > only specific ports on these hosts are available. When I change the access
    > list to only the ports it doesn't work. After going around and around TAC
    > finally comes back and says if I remove "sysopt connection permit-ipsec and
    > create access-lists and an access-group for the outside interface, but I
    > don't recommend this very much."
    >
    > Can someone explain why?
     
    wr, Nov 10, 2004
    #6
    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. Rik Bain
    Replies:
    2
    Views:
    4,234
    Walter Roberson
    Nov 13, 2003
  2. AM
    Replies:
    1
    Views:
    1,671
    Walter Roberson
    Jun 24, 2005
  3. Cen
    Replies:
    3
    Views:
    15,643
    eddied
    Jan 4, 2008
  4. Chris

    sysopt permit-ipsec

    Chris, Nov 15, 2005, in forum: Cisco
    Replies:
    2
    Views:
    4,491
    Chris
    Nov 16, 2005
  5. sigideba

    Sysopt and IPSec Packets

    sigideba, Apr 27, 2008, in forum: Cisco
    Replies:
    0
    Views:
    451
    sigideba
    Apr 27, 2008
Loading...

Share This Page