Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 1 subscriber
  • Views 1595 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

IPSEC astaro 4 with cisco pix 535

gerad
Hello,
    we're trying to setup a vpn tunnel between our astaro 4 and someone else's cisco pix 535.  

We tried many thing but so far we've been unsuccesful.  One of the things we noticed is that it doesn't look like 
ah ipsec authentication is supported.  Does anyone know when it will be since esp doesn't look too secure and freeswan does support it.

So far with esp we got the tunnel up but we never succedeed to get any packets through the tunnel, the routing doesn't seem to work correctly.

I looked in the forums and it looks like some of you got it working with a different pix model but i don't see any configuration for the pix (only cisco routers in the doc) or for the astaro.  Can someone give me a set of working parameters and a list of things to watch out for (for instance we learned we had to explicitely add a packet filter rule to allow ISAKMP even tought we had a rule with all all all)?

Thanks for your help.
  


This thread was automatically locked due to age.
Parents
  • 0
    Hi Gerard,
    the IPSEC configuration for the PIX is not very difficult:
    You have to define the vpn-peering (PSK, X.509), the encryption, the timers (changing the keys) and don't forget a accepting rule for traffic from the other side of the tunnel to the internal network behind the pix.
    Then you need a rule for secured outgoing traffic.
    And a routing definition (internal net of the opposite site route to interface of the external gateway from the pix...

    This should work at the PIX...

    At the ASL you have to define the VPN-Connection (Algorithm, X.509, PSK), no routing (will be done automatically)  and allow rule for traffic between the tunnels.

    HTH

    Regards

    Udo Seiler  
  • 0 in reply to Udo_Seiler
    Well reading your message it doesn't look like anything special needs to be done on the astaro side.  We have no control over the pix but i believe it works since the person in charge of it got freeswan to work with it so it should be ok.  We also asked him to have the esp protocol enabled since astaro doesn't allow us to use the ah method (why did they take it out of astaro anyway?)

    On the astaro side we have only have a fewpacket filter rules and they look like this:
    any ISAKMP any allow
    any any any allow

    We get the tunnel up and the routes get added in the VPN  ROUTES and when we try to connect from the remote machine we see the packet in the VPN live log but it never makes it to the internal network.

    Do you have any suggestions?
       
  • 0 in reply to gerad
    gerad,

    Please remove asap the 'ANY ANY ANY' rule it makes your firewall acting as a router without any protection. You do not need any packet filters for the VPN connection itself only filters allowing traffic from left to right and vice versa are nescessary.

    Greetings
    cyclops  
  • 0 in reply to cyclops
    Hi gerard,
    cyclops said it right.... puuhh
    did you try to send a packet from behind the pix to the astaro-side?
    Perhaps there a not the correct routings...so the tunnel will be established, but the pix didn't know where to send the packets.

    Just do a bit investigation at the logs of the pix....
    Does the packets from your astaro could go out? Or will they be blocked?

    HTH

    Regards

    Udo Seiler  
  • 0 in reply to Udo_Seiler
    Hello again,

    Let's say our connection is like this:
    A -> B -> C -> D

    A is behind astaro
    B is astaro
    C is pix
    D is behind pix

    It is my understanding that when i try to telnet from A to D, it should go through B and C and that the ip addresses that D will see will come from A.  Is that right?  To make sure that A doesn't connect to D directly we got that port blocked and when we try to connect we get a permission denied which leads us to believe that it doesn't try to go through.

    When we try to connect from D to A, we see the packets coming in on the astaro but they don't seem to go anywhere.

    As for the wide open rules, since nothing is working we're using that since we're afraid that being even more restrictive will not help.  This is a test firewall  to figure out this astaro problem.  Once we do we'll migrate the configuration settings our regular one.

    Thanks.
      
Reply
  • 0 in reply to Udo_Seiler
    Hello again,

    Let's say our connection is like this:
    A -> B -> C -> D

    A is behind astaro
    B is astaro
    C is pix
    D is behind pix

    It is my understanding that when i try to telnet from A to D, it should go through B and C and that the ip addresses that D will see will come from A.  Is that right?  To make sure that A doesn't connect to D directly we got that port blocked and when we try to connect we get a permission denied which leads us to believe that it doesn't try to go through.

    When we try to connect from D to A, we see the packets coming in on the astaro but they don't seem to go anywhere.

    As for the wide open rules, since nothing is working we're using that since we're afraid that being even more restrictive will not help.  This is a test firewall  to figure out this astaro problem.  Once we do we'll migrate the configuration settings our regular one.

    Thanks.
      
Children
  • 0 in reply to gerad
    Hi gerard,

    your first question: You're right
    Your second question: You're wrong
    -->You have to enable the appropriate port for the tunnel at the astaro.
    Like: internal_network telnet to private network behind the pix allow
    and so on...

    Packets from D to A:
    what is happening at the astaro?
    Denied and dropped? (look at the log (live)file)
    You have to create a rule like this at the astaro:
    Private network (behind the PIX) service to Private network (behind the astaro) allow.
    This worked for me....
    Don't be afraid, the packets doesn't go through the tunnel, because you define them with 'private network' (RFC...) so they can't be routed in the internet.

    HTH

    regards

    Udo Seiler
      
Cookie Information Banner