search

xelerance / Openswan

Openswan
Other
852 stars 214 forks source link

S2S VPN IPSec UTM9/Openswann problem #86

Open Reuteur opened 10 years ago

Reuteur commented 10 years ago

Hello,

We took up a VPN with a partner between a Sophos UTM 9 and firewall under Openswann.

This VPN seems totally functional for us and for our partner (No IPSec errors) but we cannot reach the web application they host.

The most disturbing, it's because when they make a ping on a machine in our LAN, we succeed in reaching the application but only in that case! As soon as they stop the ping, the application is not accessible any more.

We don't understand any more and look in vain for a solution for weeks...

Here is the topology of the VPN:

192.168.8.0/22 - > 83.X.Y.Z ( public IP) - > 195. X.Y.Z (public IP) - 10.107.10.0/25

192.168.8.0/22 is our LAN and 10.107.10.0/25 is their LAN.

IPSec policy :

IKE encryption algorithm: 3DES IKE authentication algorithm: SHA1 IKE SA lifetime: 28800 IKE DH group: Group2 MODP 1024

IPsec encryption algorithm: 3DES IPsec authentication algorithm: SHA1
IPsec SA lifetime: 3600
IPsec PFS group: Group2 : MODP 1024

Strict policy NO Compression NO

I hope you can tell me where we are wrong...

Here are logs of the connection on the Sophos firewall :

2014:08:12-14:08:52 asg320-1 pluto[6990]: "S_VPN_B_x": deleting connection 2014:08:12-14:08:52 asg320-1 pluto[6990]: "S_VPN_B_x" #100524: deleting state (STATE_QUICK_I2) 2014:08:12-14:08:52 asg320-2 pluto[7015]: id="2204" severity="info" sys="SecureNet" sub="vpn" event="Site-to-site VPN down" variant="ipsec" connection="VPN_B_x" address="83.X.Y.Z" local_net="192.168.8.0/22" remote_net="10.107.10.0/25" 2014:08:12-14:08:52 asg320-1 pluto[6990]: id="2204" severity="info" sys="SecureNet" sub="vpn" event="Site-to-site VPN down" variant="ipsec" connection="VPN_B_x" address="83.X.Y.Z" local_net="192.168.8.0/22" remote_net="10.107.10.0/25" 2014:08:12-14:08:52 asg320-1 pluto[6990]: "S_VPN_B_x" #100523: deleting state (STATE_MAIN_I4) 2014:08:12-14:08:52 asg320-2 pluto[7015]: "S_VPN_B_x": deleting connection 2014:08:12-14:08:54 asg320-2 pluto[7015]: added connection description "S_VPN_B_x" 2014:08:12-14:08:54 asg320-1 pluto[6990]: added connection description "S_VPN_B_x" 2014:08:12-14:08:54 asg320-1 pluto[6990]: "S_VPN_B_x" #100525: initiating Main Mode 2014:08:12-14:08:54 asg320-1 pluto[6990]: "S_VPN_B_x" #100525: ignoring Vendor ID payload [4f4576795c6b677a57715c73] 2014:08:12-14:08:54 asg320-1 pluto[6990]: "S_VPN_B_x" #100525: received Vendor ID payload [Dead Peer Detection] 2014:08:12-14:08:54 asg320-1 pluto[6990]: "S_VPN_B_x" #100525: received Vendor ID payload [RFC 3947] 2014:08:12-14:08:54 asg320-1 pluto[6990]: "S_VPN_B_x" #100525: enabling possible NAT-traversal with method 3 2014:08:12-14:08:54 asg320-1 pluto[6990]: "S_VPN_B_x" #100525: NAT-Traversal: Result using RFC 3947: no NAT detected 2014:08:12-14:08:54 asg320-1 pluto[6990]: "S_VPN_B_x" #100525: Peer ID is ID_IPV4_ADDR: '195.X.Y.Z' 2014:08:12-14:08:54 asg320-1 pluto[6990]: "S_VPN_B_x" #100525: Dead Peer Detection (RFC 3706) enabled 2014:08:12-14:08:54 asg320-1 pluto[6990]: "S_VPN_B_x" #100525: ISAKMP SA established 2014:08:12-14:08:54 asg320-1 pluto[6990]: "S_VPN_B_x" #100526: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP {using isakmp#100525} 2014:08:12-14:08:55 asg320-1 pluto[6990]: id="2203" severity="info" sys="SecureNet" sub="vpn" event="Site-to-site VPN up" variant="ipsec" connection="VPN_B_x" address="83.X.Y.Z" local_net="192.168.8.0/22" remote_net="10.107.10.0/25" 2014:08:12-14:08:55 asg320-1 pluto[6990]: "S_VPN_Boreus" #100526: sent QI2, IPsec SA established {ESP=>0x74f2902f <0x96e80f98 DPD} 2014:08:12-14:09:03 asg320-2 pluto[7015]: id="2203" severity="info" sys="SecureNet" sub="vpn" event="Site-to-site VPN up" variant="ipsec" connection="S_VPN_B_x" address="83.X.Y.Z" local_net="192.168.8.0/22" remote_net="10.107.10.0/25" 2014:08:12-14:09:12 asg320-1 pluto[6990]: "S_VPN_B***x" #100525: ignoring Delete SA payload: PROTO_IPSEC_ESP SA(0x35673e5f) not found (maybe expired)

I can't give you logs from the Openswan because the partner don't want to give it to me, if you can't help me, don't hesitate to close this issue.

Thanks !

simondeziel commented 10 years ago

Hi Reuteur,

On 08/14/2014 09:09 AM, Reuteur wrote:

The most disturbing, it's because when they make a ping on a machine in our LAN, we succeed in reaching the application but only in that case! As soon as they stop the ping, the application is not accessible any more.

Assuming one of the IPsec nodes is not the default gateway of the LAN, this behavior could be explain by ICMP redirect messages having a temporary effect.

On your side (192.168.8.0/22), I'd check that "ip route get 10.107.10.X" gives you the internal IP of your IPsec node.

$ ip route get 10.107.10.X 10.107.10.X via A.B.C.D dev eth0 src 192.168.8.Y cache

Where "X" is the last digit of the IP of the remote application server and the more important part is that "A.B.C.D" has to be your IPsec node's internal IP.

HTH, Simon

Reuteur commented 10 years ago

Hello Simon,

Thanks for your answer !

I try :

$ ip route get 10.107.10.40

And it answers me :

10.107.10.40 via 192.168.8.254 dev eth0 src 192.168.8.29

192.168.8.254 is the internal IP of my IPSec node.

John

De : Simon Deziel [mailto:notifications@github.com] Envoyé : jeudi 14 août 2014 15:42 À : xelerance/Openswan Cc : GONZALEZ John Objet : Re: [Openswan] S2S VPN IPSec UTM9/Openswann problem (#86)

Hi Reuteur,

On 08/14/2014 09:09 AM, Reuteur wrote:

The most disturbing, it's because when they make a ping on a machine in our LAN, we succeed in reaching the application but only in that case! As soon as they stop the ping, the application is not accessible any more.

Assuming one of the IPsec nodes is not the default gateway of the LAN, this behavior could be explain by ICMP redirect messages having a temporary effect.

On your side (192.168.8.0/22), I'd check that "ip route get 10.107.10.X" gives you the internal IP of your IPsec node.

$ ip route get 10.107.10.X 10.107.10.X via A.B.C.D dev eth0 src 192.168.8.Y cache

Where "X" is the last digit of the IP of the remote application server and the more important part is that "A.B.C.D" has to be your IPsec node's internal IP.

HTH, Simon

— Reply to this email directly or view it on GitHubhttps://github.com/xelerance/Openswan/issues/86#issuecomment-52184218.

Ensemble adoptons des gestes responsables : N'imprimez ce mail que si nécessaire.

Les informations contenues dans ce message et les pièces jointes (ci-après dénommé le message) sont confidentielles et peuvent être couvertes par le secret professionnel. Si vous n'êtes pas le destinataire de ce message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie.

Si vous avez reçu ce message par erreur, nous vous remercions de le supprimer de votre système, ainsi que toutes ses copies, et d'en avertir immédiatement bon prix France par message de retour. Il est impossible de garantir que les communications par messagerie électronique arrivent en temps utile, sont sécurisées ou dénuées de toute erreur, altération, falsification ou virus. En conséquence, bon prix France décline toute responsabilité du fait des erreurs, altérations, falsifications ou omissions qui pourraient en résulter.

Consider the environment before printing this mail.

The information contained in this e-mail is confidential. It may also be legally privileged. If you are not the addressee you may not copy, forward, disclose or use any part of it. If you have received this message by error, please delete it and all copies from your system and notify the sender immediately by return e-mail. E-mail communications cannot be guaranteed to be timely secure, error or virus-free. The sender does not accept liability for any errors or omissions which arise as a result.

simondeziel commented 10 years ago

Hi John,

Could you repeat the test from the other side (application server) and see if you get the internal IP of the Sophos?

Simon

On 08/14/2014 09:53 AM, Reuteur wrote:

Hello Simon,

Thanks for your answer !

I try :

$ ip route get 10.107.10.40

And it answers me :

10.107.10.40 via 192.168.8.254 dev eth0 src 192.168.8.29

192.168.8.254 is the internal IP of my IPSec node.

John

De : Simon Deziel [mailto:notifications@github.com] Envoyé : jeudi 14 août 2014 15:42 À : xelerance/Openswan Cc : GONZALEZ John Objet : Re: [Openswan] S2S VPN IPSec UTM9/Openswann problem (#86)

Hi Reuteur,

On 08/14/2014 09:09 AM, Reuteur wrote:

The most disturbing, it's because when they make a ping on a machine in our LAN, we succeed in reaching the application but only in that case! As soon as they stop the ping, the application is not accessible any more.

Assuming one of the IPsec nodes is not the default gateway of the LAN, this behavior could be explain by ICMP redirect messages having a temporary effect.

On your side (192.168.8.0/22), I'd check that "ip route get 10.107.10.X" gives you the internal IP of your IPsec node.

$ ip route get 10.107.10.X 10.107.10.X via A.B.C.D dev eth0 src 192.168.8.Y cache

Where "X" is the last digit of the IP of the remote application server and the more important part is that "A.B.C.D" has to be your IPsec node's internal IP.

HTH, Simon

— Reply to this email directly or view it on GitHubhttps://github.com/xelerance/Openswan/issues/86#issuecomment-52184218.

Ensemble adoptons des gestes responsables : N'imprimez ce mail que si nécessaire.

Les informations contenues dans ce message et les pièces jointes (ci-après dénommé le message) sont confidentielles et peuvent être couvertes par le secret professionnel. Si vous n'êtes pas le destinataire de ce message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie.

Si vous avez reçu ce message par erreur, nous vous remercions de le supprimer de votre système, ainsi que toutes ses copies, et d'en avertir immédiatement bon prix France par message de retour. Il est impossible de garantir que les communications par messagerie électronique arrivent en temps utile, sont sécurisées ou dénuées de toute erreur, altération, falsification ou virus. En conséquence, bon prix France décline toute responsabilité du fait des erreurs, altérations, falsifications ou omissions qui pourraient en résulter.

Consider the environment before printing this mail.

The information contained in this e-mail is confidential. It may also be legally privileged. If you are not the addressee you may not copy, forward, disclose or use any part of it. If you have received this message by error, please delete it and all copies from your system and notify the sender immediately by return e-mail. E-mail communications cannot be guaranteed to be timely secure, error or virus-free. The sender does not accept liability for any errors or omissions which arise as a result.

— Reply to this email directly or view it on GitHub https://github.com/xelerance/Openswan/issues/86#issuecomment-52185565.

Reuteur commented 10 years ago

Hi Simon,

I ask our partner to do it and I’m waiting for a feedback.

When I have the answer, I transmit it to you.

Thanks again !

John

De : Simon Deziel [mailto:notifications@github.com] Envoyé : jeudi 14 août 2014 15:57 À : xelerance/Openswan Cc : GONZALEZ John Objet : Re: [Openswan] S2S VPN IPSec UTM9/Openswann problem (#86)

Hi John,

Could you repeat the test from the other side (application server) and see if you get the internal IP of the Sophos?

Simon

On 08/14/2014 09:53 AM, Reuteur wrote:

Hello Simon,

Thanks for your answer !

I try :

$ ip route get 10.107.10.40

And it answers me :

10.107.10.40 via 192.168.8.254 dev eth0 src 192.168.8.29

192.168.8.254 is the internal IP of my IPSec node.

John

De : Simon Deziel [mailto:notifications@github.com] Envoyé : jeudi 14 août 2014 15:42 À : xelerance/Openswan Cc : GONZALEZ John Objet : Re: [Openswan] S2S VPN IPSec UTM9/Openswann problem (#86)

Hi Reuteur,

On 08/14/2014 09:09 AM, Reuteur wrote:

The most disturbing, it's because when they make a ping on a machine in our LAN, we succeed in reaching the application but only in that case! As soon as they stop the ping, the application is not accessible any more.

Assuming one of the IPsec nodes is not the default gateway of the LAN, this behavior could be explain by ICMP redirect messages having a temporary effect.

On your side (192.168.8.0/22), I'd check that "ip route get 10.107.10.X" gives you the internal IP of your IPsec node.

$ ip route get 10.107.10.X 10.107.10.X via A.B.C.D dev eth0 src 192.168.8.Y cache

Where "X" is the last digit of the IP of the remote application server and the more important part is that "A.B.C.D" has to be your IPsec node's internal IP.

HTH, Simon

— Reply to this email directly or view it on GitHubhttps://github.com/xelerance/Openswan/issues/86#issuecomment-52184218.

Ensemble adoptons des gestes responsables : N'imprimez ce mail que si nécessaire.

Les informations contenues dans ce message et les pièces jointes (ci-après dénommé le message) sont confidentielles et peuvent être couvertes par le secret professionnel. Si vous n'êtes pas le destinataire de ce message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie.

Si vous avez reçu ce message par erreur, nous vous remercions de le supprimer de votre système, ainsi que toutes ses copies, et d'en avertir immédiatement bon prix France par message de retour. Il est impossible de garantir que les communications par messagerie électronique arrivent en temps utile, sont sécurisées ou dénuées de toute erreur, altération, falsification ou virus. En conséquence, bon prix France décline toute responsabilité du fait des erreurs, altérations, falsifications ou omissions qui pourraient en résulter.

Consider the environment before printing this mail.

The information contained in this e-mail is confidential. It may also be legally privileged. If you are not the addressee you may not copy, forward, disclose or use any part of it. If you have received this message by error, please delete it and all copies from your system and notify the sender immediately by return e-mail. E-mail communications cannot be guaranteed to be timely secure, error or virus-free. The sender does not accept liability for any errors or omissions which arise as a result.

— Reply to this email directly or view it on GitHub https://github.com/xelerance/Openswan/issues/86#issuecomment-52185565.

— Reply to this email directly or view it on GitHubhttps://github.com/xelerance/Openswan/issues/86#issuecomment-52185987.

Ensemble adoptons des gestes responsables : N'imprimez ce mail que si nécessaire.

Les informations contenues dans ce message et les pièces jointes (ci-après dénommé le message) sont confidentielles et peuvent être couvertes par le secret professionnel. Si vous n'êtes pas le destinataire de ce message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie.

Si vous avez reçu ce message par erreur, nous vous remercions de le supprimer de votre système, ainsi que toutes ses copies, et d'en avertir immédiatement bon prix France par message de retour. Il est impossible de garantir que les communications par messagerie électronique arrivent en temps utile, sont sécurisées ou dénuées de toute erreur, altération, falsification ou virus. En conséquence, bon prix France décline toute responsabilité du fait des erreurs, altérations, falsifications ou omissions qui pourraient en résulter.

Consider the environment before printing this mail.

The information contained in this e-mail is confidential. It may also be legally privileged. If you are not the addressee you may not copy, forward, disclose or use any part of it. If you have received this message by error, please delete it and all copies from your system and notify the sender immediately by return e-mail. E-mail communications cannot be guaranteed to be timely secure, error or virus-free. The sender does not accept liability for any errors or omissions which arise as a result.