Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 1 subscriber
  • Views 13571 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

Need assistance with IPSEC VPN over PPPoE

CoolHandLuke
I currently have one site-to-site IPSEC tunnel configured over our primary Internet circuit, and all is working normally. We also have a DSL Internet connection that we use for backup connectivity, and I am trying to configure a IPSEC tunnel to use that connection, but with no luck. This is what I am seeing thus far:

1) I have configured the connection and everything looks good, however the tunnel never appears to try to connect. The network to which  am trying to connect is saying they never see packets from my side.

2) I have verified that I can connect to the Internet using the DSL connection, so there doesn't appear to be a problem with the circuit itself

3) When I try to start the tunnel, I'm getting this message in the live log:
ERROR: "S_Royal VPN Connection" #348: sendto on ppp0 to 207.108.247.253:500 failed in main_outI1. Errno 1: Operation not permitted

4) If I check the packet filter log, I see that the system appears to be dropping the packets it is sending out to initiate the tunnel:
11:15:05 Default DROP UDP 99.2.253.110 : 500 
 → 207.108.247.253 : 500 
 len=280 ttl=64 tos=0x00 
 
(99.2.253.110 is the static IP on my DSL connection, and 207.108.247.253 is the remote gateway to which I am trying to connect)

5) Because of the above, I specifically created packet rules (and placed at the top) to allow this traffic, including any -> any -> 207.108.247.253 and any -> IPSEC-IKE -> any... this didn't have any affect.


I'm using 7.505 on an ASG220. I would appreciate it very much if someone could give me some insight into this issue or suggest a new path to investigate. Just for clarification, I already have the DSL modem in bridge mode and allow the ASG to handle the PPPoE.


Thanks.


This thread was automatically locked due to age.
  • 0
    3), 4) & 5) Do the drops in the PF log occur only after the attempt to establish the tunnel fails?

    3) If you disable all IPsec processes and then Enable this one alone, what shows up in the IPsec log?

    Are you sure you checked 'Auto packet filter:' in the 'IPsec Connection' definition?

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson
    I can't really tell about the first question... I start seeing the drops in the PF as soon as I attempt to bring up the tunnel. I don't think the init process is ever getting to the point of doing anything other than sending the initial packets, which look like they are being dropped.

    If I disable the other IPSEC tunnel and try to bring this one up, I get exactly the same messages. Do you need me to post the IPSEC log?

    I normally do not use auto packet filter on the IPSEC connections, but I have tried it on this connection; it did not make a difference.


    Thanks for the reply.
  • 0
    Yeah, I figured the disable/enable thing would give us the clearest possible log to get a view of the problem.  It's strange that there's more than one person having IPsec issues with PPPoE right now - have you looked at the IPS log?

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson
    I assume you mean IPSEC log, but just in case - I do not use IPS on this box.

    Here is the messages from the IPSEC live log (no additional debugging levels selected)... I disables the working tunnel and started up the tunnel that wont init:

    2010:07:05-14:11:44 ASG220_1 ipsec_starter[20073]: Starting strongSwan 4.2.3 IPsec [starter]... 
    2010:07:05-14:11:44 ASG220_1 ipsec_starter[20084]: IP address or index of physical interface changed -> reinit of ipsec interface 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: Starting Pluto (strongSwan Version 4.2.3 THREADS LIBLDAP VENDORID CISCO_QUIRKS) 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: including NAT-Traversal patch (Version 0.6c) 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: ike_alg: Activating OAKLEY_AES_CBC encryption: Ok 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: ike_alg: Activating OAKLEY_BLOWFISH_CBC encryption: Ok 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: ike_alg: Activating OAKLEY_SERPENT_CBC encryption: Ok 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: ike_alg: Activating OAKLEY_SHA2_256 hash: Ok 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: ike_alg: Activating OAKLEY_SHA2_384 hash: Ok 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: ike_alg: Activating OAKLEY_SHA2_512 hash: Ok 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: ike_alg: Activating OAKLEY_TWOFISH_CBC encryption: Ok 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: ike_alg: Activating OAKLEY_TWOFISH_CBC_SSH encryption: Ok 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: Testing registered IKE encryption algorithms: 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: OAKLEY_DES_CBC self-test not available 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: OAKLEY_BLOWFISH_CBC self-test not available 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: OAKLEY_3DES_CBC self-test not available 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: OAKLEY_AES_CBC self-test not available 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: OAKLEY_SERPENT_CBC self-test not available 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: OAKLEY_TWOFISH_CBC self-test not available 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: OAKLEY_TWOFISH_CBC_SSH self-test not available 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: Testing registered IKE hash algorithms: 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: OAKLEY_MD5 hash self-test passed 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: OAKLEY_MD5 hmac self-test passed 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: OAKLEY_SHA hash self-test passed 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: OAKLEY_SHA hmac self-test passed 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: OAKLEY_SHA2_256 hash self-test passed 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: OAKLEY_SHA2_256 hmac self-test passed 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: OAKLEY_SHA2_384 hash self-test passed 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: OAKLEY_SHA2_384 hmac self-test passed 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: OAKLEY_SHA2_512 hash self-test passed 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: OAKLEY_SHA2_512 hmac self-test passed 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: All crypto self-tests passed 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: Using KLIPS IPsec interface code 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: Changing to directory '/etc/ipsec.d/cacerts' 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: loaded CA cert file 'VPN Signing CA.pem' (3229 bytes) 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: Changing to directory '/etc/ipsec.d/aacerts' 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: Changing to directory '/etc/ipsec.d/ocspcerts' 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: Changing to directory '/etc/ipsec.d/crls' 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: listening for IKE messages 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: adding interface ipsec0/ppp0 99.2.253.110:500 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: adding interface ipsec0/ppp0 99.2.253.110:4500 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: loading secrets from "/etc/ipsec.secrets" 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: loaded shared key for 207.108.247.253 99.2.253.110 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: loaded shared key for 207.108.247.253 99.2.253.110 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: loaded shared key for 207.108.247.253 99.2.253.110 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: added connection description "S_Royal VPN Connection" 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: "S_Royal VPN Connection" #1: initiating Main Mode 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: ERROR: "S_Royal VPN Connection" #1: sendto on ppp0 to 207.108.247.253:500 failed in main_outI1. Errno 1: Operation not permitted 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: added connection description "S_Royal VPN Connection" 
    2010:07:05-14:11:45 ASG220_1 pluto[20112]: added connection description "S_Royal VPN Connection" 
    2010:07:05-14:11:55 ASG220_1 pluto[20112]: ERROR: "S_Royal VPN Connection" #1: sendto on ppp0 to 207.108.247.253:500 failed in EVENT_RETRANSMIT. Errno 1: Operation not permitted 
    2010:07:05-14:12:15 ASG220_1 pluto[20112]: ERROR: "S_Royal VPN Connection" #1: sendto on ppp0 to 207.108.247.253:500 failed in EVENT_RETRANSMIT. Errno 1: Operation not permitted[/SIZE][/SIZE]
  • 0
    How about a look at the Remote Gateway and the IPsec Connection definitions?

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0
    I found what I was doing wrong... when I created the network definition for the remote gateway, I inadvertantly bound the definition to the interface connected to the DSL circuit. I changed the definition to not use any defined interface, and it is no longer dropping the packets.

    Thanks for the suggestions.
Unfiltered HTML