Automount through a PIX?

Discussion in 'Cisco' started by Wil Schultz, Feb 2, 2005.

  1. Wil Schultz

    Wil Schultz Guest

    I know, NSF through a PIX?!?! Believe me, you should have seen the
    alternative! ;)

    Anyway, I need to set up an NSF mount through from my DMZ port into the
    Inside. I have udp 111 (sunrpc) and udp 2049 (nfsd) open and I can manually
    mount a drive through the PIX. Automount, however, cannot mount the same
    drive. I will admit that I haven't spent more than 5 minutes on this, but
    it should have worked unless there are more ports that need to be opened.

    Anyone done this before? It's a production server so sniffing is next to
    useless... Ah, PIX 6.2.x (Isn't 7 done YET! ;))

    --
    Wil
    my 3¢

    "When everything seems to be going well, you have obviously overlooked
    something."
    Wil Schultz, Feb 2, 2005
    #1
    1. Advertising

  2. Hello, Wil!
    You wrote on Wed, 02 Feb 2005 07:07:54 -0800:

    WS> I know, NSF through a PIX?!?! Believe me, you should have seen
    WS> the alternative! ;)

    WS> Anyway, I need to set up an NSF mount through from my DMZ port
    WS> into the Inside. I have udp 111 (sunrpc) and udp 2049 (nfsd) open
    WS> and I can manually mount a drive through the PIX. Automount,
    WS> however, cannot mount the same drive. I will admit that I haven't
    WS> spent more than 5 minutes on this, but it should have worked
    WS> unless there are more ports that need to be opened.

    I had a working setup, but don't know if it was automounter. I did the PIX
    portion and Unix guys did NFS stuff. You should be able to see if there is
    something being denied by PIX when you are trying to use automount. BTW, is you
    NFS server in DMZ or inside?

    With best regards,
    Andrey.
    Andrey Tarasov, Feb 2, 2005
    #2
    1. Advertising

  3. In article <>,
    Wil Schultz <> wrote:
    :I know, NSF through a PIX?!?! Believe me, you should have seen the
    :alternative! ;)

    :Anyway, I need to set up an NSF mount through from my DMZ port into the
    :Inside. I have udp 111 (sunrpc) and udp 2049 (nfsd) open and I can manually
    :mount a drive through the PIX. Automount, however, cannot mount the same
    :drive.

    I haven't tried to do that, but I recently worked on something sort
    of related.

    I am running into issues with dynamic port allocation on the PIX
    when using Microsoft's RPC, officially known as the Endpoint Mapper,
    but more commonly known as netbios-ns (NETBIOS Name-service). Yeh,
    good old UDP 137.

    I wanted to know how the PIX handled MSRPC, so I went through all
    the PIX documentation, FAQs, installation guides, technical bulletins
    and so on, looking for information about MSRPC, SunRPC, NETBIOS --
    anything I could think of that was related to the general topic
    of dynamic port allocation.

    It turns out that the *only* documentation having to do with RPC
    in the PIX reference guide is:
    a) SunRPC and MSRPC are listed in the glossary in the introduction page;
    b) the 'timeout' command briefly explains that the 'rpc' timeout is
    the time until the expiration of an RPC slot.

    That's it. Nothing more.

    There is the FAQ/Technical bulletin you probably already found having
    to do with NFS/nfsd that lists the ports you note above, but automount
    is not mentioned there.

    Other than that, the *only* information I could find about SunRPC
    was in the 2.14.7 (!!) release notes saying that SunRPC support had
    been introduced and that there was no special fixup for it;
    the only information about MSRPC was in the 4.2 release notes saying
    that support had been introduced... no details. No other release
    notes or configuration guide or PIX reference manual have anything
    to say about SunRPC or MSRPC on the PIX.

    So I created a TAC case and listed all the direct or half-related pages,
    and asked to be pointed to the appropriate documentation, and I
    indicated what I was trying to do and listed all the various
    interpretations that could be put onto what little documentation
    there was.

    Well, after a week of scurrying around, the answer from the TAC was
    that they couldn't find any documentation either, and they didn't
    know how it worked! They talked to a "senior PIX engineer", who also
    didn't know how it worked!

    They've escalated the case up, over towards the people who have
    access to the code; it's too early yet to have any answers from them.


    So.... if you are thinking you just overlooked something or just didn't
    understand the documentation having to do with SunRPC on the PIX, it
    turns out that you didn't: there is so little documentation available
    that the feature might as well be absent!

    Thus all I can suggest is that you turn up your logging level
    to 6 and try an automount and see what happens, reboot [so as to
    give a chance for there to be a different port involved] and
    try again and see what happens. If you can't deduce the behaviour
    from those efforts, punt the case up to Cisco. You can reference
    case #600873878 if you want.
    --
    Those were borogoves and the momerathsoutgrabe completely mimsy.
    Walter Roberson, Feb 2, 2005
    #3
  4. Hello, Walter!
    You wrote on 2 Feb 2005 17:34:05 GMT:

    WR> I am running into issues with dynamic port allocation on the PIX
    WR> when using Microsoft's RPC, officially known as the Endpoint
    WR> Mapper,

    That would be port 135.

    WR> but more commonly known as netbios-ns (NETBIOS Name-service). Yeh, good old
    WR> UDP 137.

    And not this one.

    WR> It turns out that the *only* documentation having to do with RPC
    WR> in the PIX reference guide is:
    WR> a) SunRPC and MSRPC are listed in the glossary in the
    WR> introduction page; b) the 'timeout' command briefly explains that
    WR> the 'rpc' timeout is the time until the expiration of an RPC
    WR> slot.

    There is one curios fact about SunRPC - fixup works only from lower security
    interface to higher security. If you have a server on lower security interface,
    client on higher security and ACLs in place, you will need to open ports in
    1024-65535 range.

    With best regards,
    Andrey.
    Andrey Tarasov, Feb 2, 2005
    #4
  5. In article <ctr3d1$k02$>, Andrey Tarasov <> wrote:
    :There is one curios fact about SunRPC - fixup works only from lower security
    :interface to higher security. If you have a server on lower security interface,
    :client on higher security and ACLs in place, you will need to open ports in
    :1024-65535 range.

    Has W3C put together a coherent proposal yet for extensions to
    character elements to represent gagging?


    I have remote offices needing to access an application running on
    a W2K server, with the offices connected via VPNs (some of the
    local ISP-equivilents filter NETBIOS.) Thus no matter which site
    is client and which is server, I'm going to have both security
    transitions -- high to low as the port negotiation packet leaves
    the server into the VPN, and low to high as the port negotiation
    packet exits the VPN to go to the client. The appropriate port
    needs to be automatically opened on -both- PIXes, once so that
    the client can open the port towards the server, and once so that
    the server can receive the connection.

    What you are telling me is that This Won't Work. :(

    And no, I don't want to open up all the ports -- this is *Windows*
    and I want "security in depth" -- I don't want the laptop brought
    from home into one of the remote offices to infect our servers
    and spread from there. [I guess that's why DMZ's exist...]

    My first thought on reading your message was that I'd have to
    do something like push the data into L2TP on an inside device that
    then communicated over a VPN to an L2TP decapsulator inside,
    so that as far as the PIXen were concerned no new ports needed to
    be opened ... but any proposal like that is equivilent to just opening
    all the ports over the VPN.

    Grumble. Time to start considering the implications of moving that
    server to our DMZ. But of course, with it being a DMZ on a different
    subnet, it's going to need a different master browser than the
    internal nets, and the master browsers on the two nets are going
    to want random ports opened in order to communicate with each other.

    Does any of this get any better if I force off NETBIOS over TCP
    (ports 135, 137, 138, 139) in favour of the newer TCP 445 ?
    --
    "Infinity is like a stuffed walrus I can hold in the palm of my hand.
    Don't do anything with infinity you wouldn't do with a stuffed walrus."
    -- Dr. Fletcher, Va. Polytechnic Inst. and St. Univ.
    Walter Roberson, Feb 2, 2005
    #5
  6. Hello, Walter!
    You wrote on 2 Feb 2005 18:08:36 GMT:

    WR> Has W3C put together a coherent proposal yet for extensions to
    WR> character elements to represent gagging?

    WR> I have remote offices needing to access an application running on
    WR> a W2K server, with the offices connected via VPNs (some of the
    WR> local ISP-equivilents filter NETBIOS.) Thus no matter which site
    WR> is client and which is server, I'm going to have both security
    WR> transitions -- high to low as the port negotiation packet leaves
    WR> the server into the VPN, and low to high as the port negotiation
    WR> packet exits the VPN to go to the client. The appropriate port
    WR> needs to be automatically opened on -both- PIXes, once so that
    WR> the client can open the port towards the server, and once so that
    WR> the server can receive the connection.

    Well, I have no idea if MsRPC fixup has the same behavior or not. On the other
    hand in Windows enviroment it really boils down to an application you are
    dealing with. What are you planning to run? Is it going to be the same Active
    Directory? Is there going to be MS Exchange? Microsoft has a few articles in
    their Knowledge Base on how to make their stuff work through firewalls.

    http://support.microsoft.com/kb/280132
    http://support.microsoft.com/kb/155831

    With best regards,
    Andrey.
    Andrey Tarasov, Feb 2, 2005
    #6
  7. Wil Schultz

    none Guest

    On Wed, 02 Feb 2005 07:07:54 -0800, Wil Schultz wrote:

    > I know, NSF through a PIX?!?! Believe me, you should have seen the
    > alternative! ;)
    >
    > Anyway, I need to set up an NSF mount through from my DMZ port into the
    > Inside. I have udp 111 (sunrpc) and udp 2049 (nfsd) open and I can manually
    > mount a drive through the PIX. Automount, however, cannot mount the same
    > drive. I will admit that I haven't spent more than 5 minutes on this, but
    > it should have worked unless there are more ports that need to be opened.
    >
    > Anyone done this before? It's a production server so sniffing is next to
    > useless... Ah, PIX 6.2.x (Isn't 7 done YET! ;))


    None replies ...

    You do mean NFS right?

    We did what you want to do with routers many years ago - seems like the
    RPC was broadcast packets and we used the "ip helper" command on the
    client router end to forward it to router of the server of the NFS share.
    There's no "IP Helper" command in a PIX and I've not messed with broadcast
    on my PIX's yet - maybe someone else here can help with that.

    None
    none, Feb 3, 2005
    #7
  8. Wil Schultz

    Wil Schultz Guest

    On or somewhere about Wednesday 02 February 2005 09:32 am, Andrey Tarasov
    might have said:

    > Hello, Wil!
    > You wrote on Wed, 02 Feb 2005 07:07:54 -0800:
    >
    > WS> I know, NSF through a PIX?!?! Believe me, you should have seen
    > WS> the alternative! ;)
    >
    > WS> Anyway, I need to set up an NSF mount through from my DMZ port
    > WS> into the Inside. I have udp 111 (sunrpc) and udp 2049 (nfsd) open
    > WS> and I can manually mount a drive through the PIX. Automount,
    > WS> however, cannot mount the same drive. I will admit that I haven't
    > WS> spent more than 5 minutes on this, but it should have worked
    > WS> unless there are more ports that need to be opened.
    >
    > I had a working setup, but don't know if it was automounter. I did the PIX
    > portion and Unix guys did NFS stuff. You should be able to see if there is
    > something being denied by PIX when you are trying to use automount. BTW,
    > is you NFS server in DMZ or inside?
    >
    > With best regards,
    > Andrey.


    NFS Server is on the inside, client is on the DMZ. The mount has stayed up
    all day, but my fear is that the xlate will time out and I'll get a call at
    2:00am to ssh in and have to remount the drive.

    I didn't have time to try much today, but I'll get this bugger real soon and
    let ya'll know how it goes!

    --
    Wil
    my 3¢

    "When everything seems to be going well, you have obviously overlooked
    something."
    Wil Schultz, Feb 3, 2005
    #8
  9. Wil Schultz

    Wil Schultz Guest

    On or somewhere about Wednesday 02 February 2005 05:57 pm, none might have
    said:

    > On Wed, 02 Feb 2005 07:07:54 -0800, Wil Schultz wrote:
    >
    >> I know, NSF through a PIX?!?! Believe me, you should have seen the
    >> alternative! ;)
    >>
    >> Anyway, I need to set up an NSF mount through from my DMZ port into the
    >> Inside. I have udp 111 (sunrpc) and udp 2049 (nfsd) open and I can
    >> manually mount a drive through the PIX. Automount, however, cannot mount
    >> the same drive. I will admit that I haven't spent more than 5 minutes on
    >> this, but it should have worked unless there are more ports that need to
    >> be opened.
    >>
    >> Anyone done this before? It's a production server so sniffing is next to
    >> useless... Ah, PIX 6.2.x (Isn't 7 done YET! ;))

    >
    > None replies ...
    >
    > You do mean NFS right?
    >
    > We did what you want to do with routers many years ago - seems like the
    > RPC was broadcast packets and we used the "ip helper" command on the
    > client router end to forward it to router of the server of the NFS share.
    > There's no "IP Helper" command in a PIX and I've not messed with broadcast
    > on my PIX's yet - maybe someone else here can help with that.
    >
    > None


    Yea, not letting RPC broadcast. I have a specific rule to allow the host
    client to mount a directory on the host server.

    --
    Wil
    my 3¢

    "When everything seems to be going well, you have obviously overlooked
    something."
    Wil Schultz, Feb 3, 2005
    #9
  10. Wil Schultz

    Wil Schultz Guest

    On or somewhere about Wednesday 02 February 2005 09:34 am, Walter Roberson
    might have said:

    > In article <>,
    > Wil Schultz <> wrote:
    > :I know, NSF through a PIX?!?! Believe me, you should have seen the
    > :alternative! ;)
    >
    > :Anyway, I need to set up an NSF mount through from my DMZ port into the
    > :Inside. I have udp 111 (sunrpc) and udp 2049 (nfsd) open and I can
    > :manually mount a drive through the PIX. Automount, however, cannot mount
    > :the same drive.
    >
    > I haven't tried to do that, but I recently worked on something sort
    > of related.
    >
    > I am running into issues with dynamic port allocation on the PIX
    > when using Microsoft's RPC, officially known as the Endpoint Mapper,
    > but more commonly known as netbios-ns (NETBIOS Name-service). Yeh,
    > good old UDP 137.
    >
    > I wanted to know how the PIX handled MSRPC, so I went through all
    > the PIX documentation, FAQs, installation guides, technical bulletins
    > and so on, looking for information about MSRPC, SunRPC, NETBIOS --
    > anything I could think of that was related to the general topic
    > of dynamic port allocation.
    >
    > It turns out that the *only* documentation having to do with RPC
    > in the PIX reference guide is:
    > a) SunRPC and MSRPC are listed in the glossary in the introduction page;
    > b) the 'timeout' command briefly explains that the 'rpc' timeout is
    > the time until the expiration of an RPC slot.
    >
    > That's it. Nothing more.
    >
    > There is the FAQ/Technical bulletin you probably already found having
    > to do with NFS/nfsd that lists the ports you note above, but automount
    > is not mentioned there.
    >
    > Other than that, the *only* information I could find about SunRPC
    > was in the 2.14.7 (!!) release notes saying that SunRPC support had
    > been introduced and that there was no special fixup for it;
    > the only information about MSRPC was in the 4.2 release notes saying
    > that support had been introduced... no details. No other release
    > notes or configuration guide or PIX reference manual have anything
    > to say about SunRPC or MSRPC on the PIX.
    >
    > So I created a TAC case and listed all the direct or half-related pages,
    > and asked to be pointed to the appropriate documentation, and I
    > indicated what I was trying to do and listed all the various
    > interpretations that could be put onto what little documentation
    > there was.
    >
    > Well, after a week of scurrying around, the answer from the TAC was
    > that they couldn't find any documentation either, and they didn't
    > know how it worked! They talked to a "senior PIX engineer", who also
    > didn't know how it worked!
    >
    > They've escalated the case up, over towards the people who have
    > access to the code; it's too early yet to have any answers from them.
    >
    >
    > So.... if you are thinking you just overlooked something or just didn't
    > understand the documentation having to do with SunRPC on the PIX, it
    > turns out that you didn't: there is so little documentation available
    > that the feature might as well be absent!
    >
    > Thus all I can suggest is that you turn up your logging level
    > to 6 and try an automount and see what happens, reboot [so as to
    > give a chance for there to be a different port involved] and
    > try again and see what happens. If you can't deduce the behaviour
    > from those efforts, punt the case up to Cisco. You can reference
    > case #600873878 if you want.


    You know, you just gave me an idea... If the senior PIX "guy" doesn't know,
    the UNIX "guy's" should. So, is M$RPC part of the "Unix services for
    Windows"?

    --
    Wil
    my 3¢

    "When everything seems to be going well, you have obviously overlooked
    something."
    Wil Schultz, Feb 3, 2005
    #10
  11. Wil Schultz

    Wil Schultz Guest

    On or somewhere about Wednesday 02 February 2005 08:17 pm, Wil Schultz might
    have said:

    <snip>
    >> I haven't tried to do that, but I recently worked on something sort
    >> of related.

    <snip>

    Hey Walter, I haven't tried this yet but I found a good doc that looks like
    it has the answer to both of our problems. I don't know that I like it, but
    looks like it has the answer.

    http://www.cisco.com/en/US/products...od_release_note09186a00800f254b.html#xtocid48

    --
    Wil
    my 3¢

    "When everything seems to be going well, you have obviously overlooked
    something."
    Wil Schultz, Feb 3, 2005
    #11
  12. Wil Schultz

    Wil Schultz Guest

    <snip>

    Looks like you hit this one right on the head Andrey. Thanks! I'll report
    back later with the results...

    Very disturbing is the fact that Cisco PIX Doc's from 5.x and up do not have
    this information. They go through the RPC (111) and NFS (2049) ports but
    blatently leave out the higher dynamic ports that portmapper requires.

    --
    Wil
    my 3¢

    "When everything seems to be going well, you have obviously overlooked
    something."
    Wil Schultz, Feb 3, 2005
    #12
  13. As a suggestion, don't use conduits in your configuration; they're being
    phased out.

    I did a google of 'NFS fixup' and voila!
    http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_62/config/fixu
    p.htm#xtocid28



    On 02/03/2005 09:03 AM, in article , "Wil
    Schultz" <> wrote:

    > <snip>
    >
    > Looks like you hit this one right on the head Andrey. Thanks! I'll report
    > back later with the results...
    >
    > Very disturbing is the fact that Cisco PIX Doc's from 5.x and up do not have
    > this information. They go through the RPC (111) and NFS (2049) ports but
    > blatently leave out the higher dynamic ports that portmapper requires.
    Brant I. Stevens, Feb 6, 2005
    #13
    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. Jason Kau

    VPN through PIX to PIX

    Jason Kau, Jul 24, 2003, in forum: Cisco
    Replies:
    1
    Views:
    3,999
    Marc Van der Sypt
    Jul 25, 2003
  2. J Bard
    Replies:
    2
    Views:
    4,013
    J Bard
    Jan 10, 2004
  3. Andrew J Instone-Cowie

    Cisco VPN through a PIX 501 to another PIX?

    Andrew J Instone-Cowie, Jan 20, 2004, in forum: Cisco
    Replies:
    5
    Views:
    4,133
    Andrew J Instone-Cowie
    Jan 22, 2004
  4. nordberg
    Replies:
    1
    Views:
    519
  5. wewa
    Replies:
    10
    Views:
    1,055
    Andre Da Costa [Extended64]
    Jun 19, 2005
Loading...

Share This Page