<div dir="ltr">I agree - why would an ISP need to track connections? (Unless they were behind CGNAT)<br><div><br><div class="gmail_quote"><div dir="ltr">On Tue, Feb 16, 2016 at 10:58 AM Mark Andrews <<a href="mailto:marka@isc.org">marka@isc.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
In message <PS1PR03MB165960988F25CAA3586E14D496AC0@PS1PR03MB1659.apcprd03.prod.<br>
<a href="http://outlook.com" rel="noreferrer" target="_blank">outlook.com</a>>, Tristram Cheer writes:<br>
><br>
> Hi All,<br>
><br>
> I came across a client on our network that is using a filtering service<br>
> where the client installs a device that sends all of their upload traffic<br>
> over an IPSec tunnel to a 3rd party network for inspection before that<br>
> network then sends the request on with  the "spoofed" IP of the client's<br>
> public IP so that the download stream returns directly to the client.<br>
> This way the filtering service doesn't have to deal with the download<br>
> traffic volumes. Initially It seemed ok but the more I thought about it<br>
> the more it didn't sit right with me.<br>
<br>
It's not spoofed if it originated from the client.  The outgoing<br>
traffic almost certainly has the public address before it enters<br>
the IPSec tunnel so that the reply traffic can be correctly reverse<br>
NATed otherwise it doesn't have the necessary state.<br>
<br>
inside <-> NAT <-          ISP           <- world<br>
               \                            /<br>
                -> IPSec Tunnel -> filter >-<br>
<br>
> Has anyone else come across this type of service before? Have you run<br>
> into problems with what is in effect one way traffic from a<br>
> SME/Residential connection? It seems to me that BCP38 would knock this<br>
> service out and if the ISP was doing any sort of inspection that would<br>
> require both up and down streams it may break their connection/degrade<br>
> it. Whilst it's technically ok it just seems a little off for a<br>
> non-enterprise connection to potentially be acting "odd". Not looking at<br>
> the pro's and con's of filtering but just thought I'd put it to the list<br>
> to see what everyone's thoughts are on it :)<br>
<br>
Why should the ISP care about seeing both sides of a stream?  The<br>
ISP's job is to ship packets.  Asymetric routing happens all the<br>
time.  This is just a example of it.<br>
<br>
> Cheers<br>
><br>
><br>
> TRISTRAM CHEER<br>
> UBER GROUP LIMITED<br>
> NETWORK ARCHITECT - MOST PROBLEMS ARE THE RESULT OF PREVIOUS SOLUTIONS...<br>
><br>
> [Facebook]<<a href="https://www.facebook.com/UberGroup?_rdr=p" rel="noreferrer" target="_blank">https://www.facebook.com/UberGroup?_rdr=p</a>> [Twitter]<br>
> <<a href="https://twitter.com/ubergroupltd" rel="noreferrer" target="_blank">https://twitter.com/ubergroupltd</a>><br>
><br>
> E: <a href="mailto:t@uber.co.nz" target="_blank">t@uber.co.nz</a><mailto:<a href="mailto:t@uber.co.nz" target="_blank">t@uber.co.nz</a>><br>
> P: 09 438 5472 Ext 803 | M: 022 412 1985 | W:<br>
> <a href="http://www.uber.co.nz" rel="noreferrer" target="_blank">www.uber.co.nz</a><<a href="http://www.uber.co.nz" rel="noreferrer" target="_blank">http://www.uber.co.nz</a>><br>
> 53 PORT ROAD | PO BOX 5083 | WHANGAREI | NEW ZEALAND<br>
--<br>
Mark Andrews, ISC<br>
1 Seymour St., Dundas Valley, NSW 2117, Australia<br>
PHONE: +61 2 9871 4742                 INTERNET: <a href="mailto:marka@isc.org" target="_blank">marka@isc.org</a><br>
_______________________________________________<br>
AusNOG mailing list<br>
<a href="mailto:AusNOG@lists.ausnog.net" target="_blank">AusNOG@lists.ausnog.net</a><br>
<a href="http://lists.ausnog.net/mailman/listinfo/ausnog" rel="noreferrer" target="_blank">http://lists.ausnog.net/mailman/listinfo/ausnog</a><br>
</blockquote></div></div></div>