[prev in list] [next in list] [prev in thread] [next in thread]
List: libreswan
Subject: Re: [Swan] Cannot ping the other end
From: Xinwei Hong <xhong () skytap ! com>
Date: 2017-01-20 6:28:15
Message-ID: CACVTCzx=zOixrRGrX1_1JUktPkS-suBeqB734Gr1En9DvKeMvQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Thank you so much. Just double checked, I got all expected results as what
you mentioned here. It all makes sense now.
Thanks,
Xinwei
On Thu, Jan 19, 2017 at 8:33 PM, Paul Wouters <paul@nohats.ca> wrote:
> On Thu, 19 Jan 2017, Xinwei Hong wrote:
>
> Thank you very much. After I enable IP forwarding and add sourceip, things
>> are working now. The send_redirects/accept_redirects seems does not
>> matter.
>> Regarding sourceip, you mentioned.
>> "Of course, if the IPsec server is just routing the entire /24 elsewhere,
>> this does not apply."
>> In my case, I do want route the entire /24 to remote. Can you confirm,
>> sourceip is required even in this case?
>>
>
> the sourceip is required only if you want the ipsec gateway itself
> to talk to the remote subnet. Then it needs to be convinced to use
> the internal instead of external ip. If you are just routing it to
> another machine, then if you want to reach the remote subnet on
> the ipsec server, you would need another tunnel definition from the
> ipsec server itself to the remote subnet. So you would add it
> without leftsubnet= so that it is a tunnel from "left" to "rightsubnet"
>
> Last time, when I set up VTI support, sourceip seems was not required.
>>
>
> Yes. With VTI, routes are used to determine what gets encrypted, and
> a route for the remote subnet in the VTI interface causes the
> encryption to happen. Of course, the tunnel policy still needs to
> include the src/dst IP combo, but often VTI tunnels use subnets of
> 0.0.0.0/0 so anything routed into it will just work.
>
> Paul
>
[Attachment #5 (text/html)]
<div dir="ltr">Thank you so much. Just double checked, I got all expected results as \
what you mentioned here. It all makes sense \
now.<div><br></div><div>Thanks,</div><div>Xinwei</div></div><div \
class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 19, 2017 at 8:33 PM, \
Paul Wouters <span dir="ltr"><<a href="mailto:paul@nohats.ca" \
target="_blank">paul@nohats.ca</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><span class="">On Thu, 19 Jan 2017, Xinwei Hong wrote:<br> \
<br> </span><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> Thank you very much. After I \
enable IP forwarding and add sourceip, things<br> are working now. The \
send_redirects/accept_redirect<wbr>s seems does not matter.<br> Regarding sourceip, \
you mentioned.<br> "Of course, if the IPsec server is just routing the entire \
/24 elsewhere,<br> this does not apply."<br>
In my case, I do want route the entire /24 to remote. Can you confirm,<br>
sourceip is required even in this case?<br>
</blockquote>
<br></span>
the sourceip is required only if you want the ipsec gateway itself<br>
to talk to the remote subnet. Then it needs to be convinced to use<br>
the internal instead of external ip. If you are just routing it to<br>
another machine, then if you want to reach the remote subnet on<br>
the ipsec server, you would need another tunnel definition from the<br>
ipsec server itself to the remote subnet. So you would add it<br>
without leftsubnet= so that it is a tunnel from "left" to \
"rightsubnet"<span class=""><br> <br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> Last time, when I set up VTI support, sourceip seems was not \
required.<br> </blockquote>
<br></span>
Yes. With VTI, routes are used to determine what gets encrypted, and<br>
a route for the remote subnet in the VTI interface causes the<br>
encryption to happen. Of course, the tunnel policy still needs to<br>
include the src/dst IP combo, but often VTI tunnels use subnets of<br>
<a href="http://0.0.0.0/0" rel="noreferrer" target="_blank">0.0.0.0/0</a> so anything \
routed into it will just work.<span class="HOEnZb"><font color="#888888"><br> <br>
Paul<br>
</font></span></blockquote></div><br></div>
_______________________________________________
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic