nat routes internal ip's over extrenal networks lan ips over wan networks

[p1ruj3]

Hardy
tcpdump -i ppp0

01:05:50.337659 IP 10.10.0.10.60726 > unknown.nscnap.net.www: F 0:0(0) ack 1 win 65535

6 pages of information and trouble shooting at -
http://tennessee.ubuntuforums.com/showthread.php?s=8a1250eda87f9cede861165a9b79204a&t=906126

I confirmed the problem with my original belief. Anyone dealing with verizon it took me over 2 hours of heated supervisor to supervisor hopping until i finally got a guy willing to help provide me with the information i needed. Which he in turn had their tech team monitor my connection for a a day after the ticket had to be escalated several times (over a two week process)

In the end this is the confirmed problem. Because i have had this issue on several different ubuntu machines, i am certain it is an issue in ubuntu iptables or routing. The bottom line is right now windows is a more stable platform for ics, which makes me sick...

The problem is its routing my lan ip's over the wan (or randomly bridging the connection rather then routing it) my terminology might be off, verizon explained it to me "it is leaking internal ip address's to our network which is why we are disconnecting you"

this is exactly what i guessed was going on as my tcpdump logs show
<code>
(example)
tcpdump -i ppp0 -v
10.10.0.x > google.com
</code>

I have tried setting up my ics through the tutorial, through guide + guard dog , and through firestarter

[Andres Mujica (andres.mujica)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. This bug did not have a package associated with it, which is important for ensuring that it gets looked at by the proper developers. You can learn more about finding the right package at https://wiki.ubuntu.com/Bugs/FindRightPackage . I have classified this bug as a bug in PPP.
For future reference you might be interested to know that a lot of applications have bug reporting functionality built in to them. This can be accessed via the Report a Problem option in the Help menu for the application with which you are having an issue. You can learn more about this feature at https://wiki.ubuntu.com/ReportingBugs.

[kernel-janitor (kernel-janitor)]

Hi p1ruj3,

This bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? Can you try with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/releases/ .

If it remains an issue, could you run the following command from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux 269081

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

[HappyCamper (colin-conway)]

This looks like the same problem I'm having. Most NAT is happening, but every so often an internal IP is 'leaking' through. The leaked ones don't appear to be any different to similar non-leaked ones. The only pattern I have noticed so far is that they all seem to originate from Opera 10.01, but I don't know if that could actually make a difference.

I do know that I started seeing this problem at about 3pm on October 29th, because I was half way through updating my laptop to the new release. I haven't updated either the server (which has the USB727 in it) or my desktop yet though. The leaked packet come from both my laptop and my desktop.

I've included some system info below, but let me know if you need more

[code]
SERVER:
Description: Ubuntu 9.04
Release: 9.04

ppp:
  Installed: 2.4.5~git20081126t100229-0ubuntu2
  Candidate: 2.4.5~git20081126t100229-0ubuntu2
  Version table:
 *** 2.4.5~git20081126t100229-0ubuntu2 0
        500 http://us.archive.ubuntu.com jaunty/main Packages
        100 /var/lib/dpkg/status
bind9:
  Installed: 1:9.5.1.dfsg.P2-1ubuntu0.1
  Candidate: 1:9.5.1.dfsg.P2-1ubuntu0.1
  Version table:
 *** 1:9.5.1.dfsg.P2-1ubuntu0.1 0
        500 http://us.archive.ubuntu.com jaunty-updates/main Packages
        500 http://security.ubuntu.com jaunty-security/main Packages
        100 /var/lib/dpkg/status
     1:9.5.1.dfsg.P2-1 0
        500 http://us.archive.ubuntu.com jaunty/main Packages

DESKTOP:
opera:
  Installed: 10.01.4682.gcc4.qt3
  Candidate: 10.01.4682.gcc4.qt3
  Version table:
 *** 10.01.4682.gcc4.qt3 0
        500 http://deb.opera.com stable/non-free Packages
        100 /var/lib/dpkg/status
[/code]

[HappyCamper (colin-conway)]

I forgot to put the computer details in:

SERVER: Linux redneck 2.6.28-16-server #55-Ubuntu SMP Tue Oct 20 20:37:10 UTC 2009 x86_64 GNU/Linux

DESKTOP: Linux duckpond 2.6.28-16-generic #55-Ubuntu SMP Tue Oct 20 19:48:32 UTC 2009 x86_64 GNU/Linux

[HappyCamper (colin-conway)]

I found the cause of the problem on my computer. I'm not sure if it's a bug, or by design.

Packets that are INVALID (rather than NEW, ESTABLISHED or RELATED) don't get translated when they go through the NAT. I don't know what makes them invalid, they look the same as other that are ok from the same source, but it was the fact that I stopped limiting my network to ppp forwarding to NEW, ESTABLISHED or RELATED packets that caused my issue.

Should they be left untranslated? Should they be considered INVALID in the first place? I don't know, but I'm glad I finally worked it out.

[dino99 (9d9)]

closing that old report, as it has not got recent comment.