IPSec + rdesktop/samba problem.

Discussion in 'Cisco' started by =?iso-8859-2?q?Micha=B3_Iwaszko?=, Jan 27, 2005.

  1. Hi all.

    I have a problem with an IPSec tunnel between two routers:
    Router 1:
    Cisco IOS Software, C1700 Software (C1700-K9O3SY7-M), Version 12.3(8)T5,
    RELEASE SOFTWARE (fc2)
    Router 2:
    IOS (tm) C2600 Software (C2600-IK2S-M), Version 12.1(24), RELEASE SOFTWARE
    (fc2)

    These are parts of my configuration files:
    Router 1:
    http://pastebin.ca/4837
    Router 2:
    http://pastebin.ca/4838

    The problem seems complicated, because when I add the 'crypto map private'
    to the serial subinterfaces rdesktop stops working. Samba seems working,
    but only to 'the first click'. I can only enter into one directory and
    than it times out if I click something else. WWW times out sometimes too.
    Only things like ping, telnet, ssh work. If I do 'no crypto map private',
    everything starts working just great. I really don't know where the
    problem is, and I have to make it work as fast as I can.

    PS. Excuse me for my english, for I'm not a native english speaker :)

    --
    Micha³ Iwaszko
     
    =?iso-8859-2?q?Micha=B3_Iwaszko?=, Jan 27, 2005
    #1
    1. Advertising

  2. Michal,
    it looks like your broadcasts are not getting through the tunnel. Try
    adding helper addresses to the routers. If the users sign on to a
    particular remote server, use:
    interface ethernet 0
    ip helper-address <ip address of remote server>
    or, if it is a the whole remote network you need to do:
    interface ethernet 0
    ip helper-address <broadcast address of remote network, like
    10.0.2.255>
    Let me know if it improves.
    Regards,
    Daniel
    www.CherryFive.com
     
    Daniel Prinsloo - www.CherryFive.com, Jan 27, 2005
    #2
    1. Advertising

  3. =?iso-8859-2?q?Micha=B3_Iwaszko?=

    Hansang Bae Guest

    Micha³ Iwaszko wrote:

    >
    > Hi all.
    >
    > I have a problem with an IPSec tunnel between two routers:
    > Router 1:
    > Cisco IOS Software, C1700 Software (C1700-K9O3SY7-M), Version
    > 12.3(8)T5, RELEASE SOFTWARE (fc2)
    > Router 2:
    > IOS (tm) C2600 Software (C2600-IK2S-M), Version 12.1(24), RELEASE
    > SOFTWARE (fc2)
    >
    > These are parts of my configuration files:
    > Router 1:
    > http://pastebin.ca/4837
    > Router 2:
    > http://pastebin.ca/4838
    >
    > The problem seems complicated, because when I add the 'crypto map
    > private' to the serial subinterfaces rdesktop stops working. Samba
    > seems working, but only to 'the first click'. I can only enter into
    > one directory and than it times out if I click something else. WWW
    > times out sometimes too. Only things like ping, telnet, ssh work. If
    > I do 'no crypto map private', everything starts working just great. I
    > really don't know where the problem is, and I have to make it work as
    > fast as I can.
    >
    > PS. Excuse me for my english, for I'm not a native english speaker :)


    Sounds like your Path-MTU discovery is not working for whatever reason
    (IOS limitation of sending ICMPs per interface, ACL, or FW)

    But you can easily get around this by increasing the physical MTU on
    your serial link.

    Start with your remote site and do

    ! just in case
    wr mem
    reload in 10
    !
    interface Serial0/0
    mtu 1600

    Now do the near side.

    --

    hsb


    "Somehow I imagined this experience would be more rewarding" Calvin
    **************************ROT13 MY ADDRESS*************************
    Due to the volume of email that I receive, I may not not be able to
    reply to emails sent to my account. Please post a followup instead.
    ********************************************************************
     
    Hansang Bae, Jan 28, 2005
    #3
  4. =?iso-8859-2?q?Micha=B3_Iwaszko?=

    Hansang Bae Guest

    Hansang Bae wrote:
    > reload in 10



    Forgot to add....you can use "reload cancel" to stop it from rebooting.


    hsb


    "Somehow I imagined this experience would be more rewarding" Calvin
    **************************ROT13 MY ADDRESS*************************
    Due to the volume of email that I receive, I may not not be able to
    reply to emails sent to my account. Please post a followup instead.
    ********************************************************************
     
    Hansang Bae, Jan 29, 2005
    #4
  5. Fri, 28 Jan 2005 05:46:12 +0000, Hansang Bae wrote:


    > Start with your remote site and do
    >
    > ! just in case
    > wr mem
    > reload in 10
    > !
    > interface Serial0/0
    > mtu 1600
    >
    > Now do the near side.


    But there's an another small problem. I can't change my MTU on a FR
    sub-interface, and I can't change on the whole serial interface.

    --
    Micha³ Iwaszko
     
    =?iso-8859-2?q?Micha=B3_Iwaszko?=, Jan 31, 2005
    #5
  6. =?iso-8859-2?q?Micha=B3_Iwaszko?=

    Hansang Bae Guest

    Micha³ Iwaszko wrote:
    > But there's an another small problem. I can't change my MTU on a FR
    > sub-interface,


    that is correct. It grabs the value from the major interface.

    > and I can't change on the whole serial interface.


    Then you're options are - in no particular order:

    1) Hse the TCP MSS hijacking technique (tcp mss-adjust ??) available
    in later codes. Of course it won't due anything for udp traffic.
    2) Find out who's blocking your ICMP3/4's. Daunting task unless your
    FWs are doing it.
    3) Reduce the ethernet MTU on all the PCs. Kludge at best but what
    can you do.



    --

    hsb


    "Somehow I imagined this experience would be more rewarding" Calvin
    **************************ROT13 MY ADDRESS*************************
    Due to the volume of email that I receive, I may not not be able to
    reply to emails sent to my account. Please post a followup instead.
    ********************************************************************
     
    Hansang Bae, Jan 31, 2005
    #6
  7. Mon, 31 Jan 2005 16:08:51 +0000, Hansang Bae wrote:

    > Micha³ Iwaszko wrote:
    >> But there's an another small problem. I can't change my MTU on a FR
    >> sub-interface,

    >
    > that is correct. It grabs the value from the major interface.
    >
    >> and I can't change on the whole serial interface.

    >
    > Then you're options are - in no particular order:
    >
    > 1) Hse the TCP MSS hijacking technique (tcp mss-adjust ??) available in
    > later codes. Of course it won't due anything for udp traffic. 2) Find
    > out who's blocking your ICMP3/4's. Daunting task unless your FWs are
    > doing it.
    > 3) Reduce the ethernet MTU on all the PCs. Kludge at best but what can
    > you do.


    I discarded option 3 at first. Then I've checked option 2 and this ICMP
    type 3/4 firewalling thing turned to be a misunderstanding, because I
    receive those packets. That's a tcpdump output (pinging with hping2 -C 3/4):

    14:59:27.960256 IP 10.0.0.98 > 10.0.12.200: icmp 36: net 5.6.7.8
    unreachable
    14:59:47.980709 IP 10.0.0.98 > 10.0.12.200: icmp 36: source quench

    What can I do now? Set the TCP MSS value to a higher one? If so, than
    there's a small question. What should I set this value to? (1460 is for a
    normal ethernet packet, right?)

    --
    Micha³ Iwaszko
     
    =?iso-8859-2?q?Micha=B3_Iwaszko?=, Feb 1, 2005
    #7
  8. =?iso-8859-2?q?Micha=B3_Iwaszko?=

    Hansang Bae Guest

    Micha³ Iwaszko wrote:
    > I discarded option 3 at first. Then I've checked option 2 and this
    > ICMP type 3/4 firewalling thing turned to be a misunderstanding,
    > because I receive those packets. That's a tcpdump output (pinging
    > with hping2 -C 3/4):
    >
    > 14:59:27.960256 IP 10.0.0.98 > 10.0.12.200: icmp 36: net 5.6.7.8
    > unreachable
    > 14:59:47.980709 IP 10.0.0.98 > 10.0.12.200: icmp 36: source quench
    >
    > What can I do now? Set the TCP MSS value to a higher one? If so, than
    > there's a small question. What should I set this value to? (1460 is
    > for a normal ethernet packet, right?)


    You don't want to *send* icmp 3/4s You need to *receive* them. So a
    better test is to send a 1472 packet (8 bytes for ICMP, 20 bytes for IP
    ==1500) with the do not fragment set (i.e. -y option in hping)



    --

    hsb


    "Somehow I imagined this experience would be more rewarding" Calvin
    **************************ROT13 MY ADDRESS*************************
    Due to the volume of email that I receive, I may not not be able to
    reply to emails sent to my account. Please post a followup instead.
    ********************************************************************
     
    Hansang Bae, Feb 3, 2005
    #8
  9. Thu, 03 Feb 2005 02:56:38 +0000, Hansang Bae wrote:

    > Micha³ Iwaszko wrote:
    >> I discarded option 3 at first. Then I've checked option 2 and this ICMP
    >> type 3/4 firewalling thing turned to be a misunderstanding, because I
    >> receive those packets. That's a tcpdump output (pinging with hping2 -C
    >> 3/4):
    >>
    >> 14:59:27.960256 IP 10.0.0.98 > 10.0.12.200: icmp 36: net 5.6.7.8
    >> unreachable
    >> 14:59:47.980709 IP 10.0.0.98 > 10.0.12.200: icmp 36: source quench
    >>
    >> What can I do now? Set the TCP MSS value to a higher one? If so, than
    >> there's a small question. What should I set this value to? (1460 is for
    >> a normal ethernet packet, right?)

    >
    > You don't want to *send* icmp 3/4s You need to *receive* them. So a
    > better test is to send a 1472 packet (8 bytes for ICMP, 20 bytes for IP
    > ==1500) with the do not fragment set (i.e. -y option in hping)


    I've done something like this:
    (sophie is my box in 10.0.0.0/24, and cntrm-bialystok is an another one in
    10.0.12.0/24 - I'm pinging from sophie and tcpdumping at cntrm-bialystok)

    First, an ECHO_REQUEST:
    sophie:
    # hping -y -C 8 -d 1472 10.0.12.200
    HPING 10.0.12.200 (xl0 10.0.12.200): icmp mode set, 28 headers + 1472 data
    bytes
    len=788 ip=10.0.12.200 ttl=62 DF id=51748 icmp_seq=0 rtt=373.9 ms

    cntrm-bialystok:
    09:25:04.190401 IP sophie.localdomain > cntrm-bialystok: icmp 1480: echo
    request seq 0
    09:25:04.190456 IP cntrm-bialystok > sophie.localdomain: icmp 1480: echo reply
    seq 0

    And than an ICMP_UNREACH:
    sophie:
    # hping -y -C 3 -d 1472 10.0.12.200
    HPING 10.0.12.200 (xl0 10.0.12.200): icmp mode set, 28 headers + 1472 data
    bytes
    ^C

    cntrm-bialystok:
    09:27:00.356331 IP sophie.localdomain > cntrm-bialystok: icmp 1480: net 5.6.7.8
    unreachable
    09:27:00.361331 IP sophie.localdomain > cntrm-bialystok: icmp

    It looks as if it's all right... But I still don't know what to do...

    --
    Micha³ Iwaszko
     
    =?iso-8859-2?q?Micha=B3_Iwaszko?=, Feb 3, 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. Raffi
    Replies:
    4
    Views:
    926
    Raffi
    Feb 6, 2004
  2. Mirek

    Samba PDC and PIX Firewall

    Mirek, Feb 19, 2004, in forum: Cisco
    Replies:
    0
    Views:
    477
    Mirek
    Feb 19, 2004
  3. John
    Replies:
    1
    Views:
    556
    Walter Roberson
    Oct 4, 2005
  4. DaveT
    Replies:
    8
    Views:
    570
  5. DaveT
    Replies:
    15
    Views:
    1,258
    Marlin Munrow
    Nov 6, 2003
Loading...

Share This Page