Guest User!

You are not Sophos Staff.

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

US Dept of Defense integrated into L2TP VPN?

SalishSwede
My carrier, Sprint is using legacy DoD addresses for cell phone connections but there appears to be something wrong with the VPN functionality... see posts later in this thread.

I'm connecting my smartphone to my local home net using L2TP via the Sophos UTM.

I'm reviewing the firewall logs and notice traffic on port 443 being blocked between two addresses:  
Source:

21.194.27.36  Dept of Defense

Dest:

50.115.125.93   [URL="http://mxtoolbox.com/SuperTool.aspx?action=ptr%3a50.115.125.93&run=toolpage#"]50.115.125.93.static.westdc.net  ??
[/URL]

              69.171.245.49   Facebook

Here's what I can find on the source:
[SIZE=2]Location[/SIZE]                     [SIZE=2]  UNITED STATES, OHIO, COLUMBUS[/SIZE]                                                       [SIZE=2]Latitude, Longitude[/SIZE]                     [SIZE=2]39.96638, -83.01277 (39°57'59"S   -83°0'46"E)[/SIZE]                                                       [SIZE=2]Connection through[/SIZE]                     [SIZE=2]DOD NETWORK INFORMATION CENTER[/SIZE]                                                       [SIZE=2]Local Time[/SIZE]                     [SIZE=2]04 Dec, 2013 05:17 PM (UTC -05:00)[/SIZE]                                                       [SIZE=2]Domain[/SIZE]                     [SIZE=2]NIC.MIL[/SIZE]
Here are a couple of lines from the logs:

[FONT=monospace]14:08:16 Packet filter rule #6 L2TP 21.194.27.36 : 39669 → 50.115.125.93 : 443 [RST] len=40 ttl=63 tos=0x00 srcmac=0:0:2f[:D]2:32:f7
[/FONT]
[FONT=monospace]14:08:19 Packet filter rule #6 L2TP 21.194.27.36 : 39669 → 50.115.125.93 : 443 [RST] len=40 ttl=63 tos=0x00 srcmac=0:0:2f[:D]2:32:f7
[/FONT]
[FONT=monospace]14:08:19 Packet filter rule #6 L2TP 21.194.27.36 : 38247 → 69.171.245.49 : 443 [ACK PSH] len=130 ttl=63 tos=0x00 srcmac=0:0:2f[:D]2:32:f7
[/FONT]
[FONT=monospace]14:08:26 Packet filter rule #6 L2TP 21.194.27.36 : 39669 → 50.115.125.93 : 443 [RST] len=40 ttl=63 tos=0x00 srcmac=0:0:2f[:D]2:32:f7
[/FONT]
 
Note the L2TP is the traffic being parsed. 

Could I get some fresh eyes on this?

Thanks,

Doug


This thread was automatically locked due to age.
  • 0 in reply to BarryG
    Good catch.  I'll review and update. 
    Update: it was just a duplicate.  IT seems complete per IANA's site.
  • 0 in reply to SalishSwede
    [SIZE=2][FONT=Arial]Fascinating.  
    It seems the DoD is  indeed inserting itself into the VPN traffic created between my devices  and the UTM.  They appear to be redirecting VPN traffic through their datacenters. Due to the strange set of firewall rules I created, a  partial connection is made between the DoD and services elsewhere which include Facebook.  When half of the traffic is blocked and logged the traffic becomes evident to the firewall.  I'll fiddle with the rules and see if I can find out more.  

    I assume this will be corrected by the spooks involved at some point, however.  It remains to be seen how quickly.
    [/FONT][/SIZE]
  • 0 in reply to SalishSwede
    Note: this is further evidence that the Executive Branch of the US government has completely disregarded the Bill of Rights.

    My conclusion:  L2TP has been completely compromised and should be avoided at all costs.  L2TP thus joins PPTP in the category of "Worse than Useless" for security protocols.
  • 0
    Hi,

    On the traceroute, I was asking if you could try a traceroute to the DOD address to see if it's going out your internet connection (as it should), or through the VPN to the phone (which would be weird but would at least make some sense based upon the logs).

    On the MAC address: MACs are ALWAYS LOCAL.
    That is why I asked what that address is.

    re the log... all the packets are RST or ACK PSH.
    If you're blocking all traffic from the DoD addresses, then these don't make a lot of sense by themselves.
    Are you using the UTM's HTTPS proxy on your VPN client (phone)?

    All of this is weird, but imho it's early to be jumping to conclusions.

    Barry
  • 0
    Duogga,

    If you are seeing a DoD IP Address tied to a MAC in your logs, I doubt it's actually the DoD.

    I've heard of instances (may have been referenced on this forum) where smaller Cell Carriers and/or ISP's, needing Carrier Grade NAT(CGN) either due to inability or unwillingness to purchase netblocks from IANA and not wanting to use the traditional 10.0.0.0/8, have resorted to 'borrowing' various /8 subnets that are they're reasonably confident aren't in use globally, such as the DoD.

    I think in this forum some people noticed one Cell provider using IP's assigned to the UK's version of the DoD. That you're seeing a MAC address of hardware from a company specializing in last mile ATM/TDM/Cell access devices, I wonder if perhaps your cell carrier is using CGN in combo with a borrowed netblock?

    From what I understand about DoD and NSA practices regarding electronic tapping, the taps used are virtually invisible as they aren't "in the way" so to speak. The technique they use is similar to port mirroring on higher end switches. Port Mirroing on a switch basically sends a copy of all traffic on a specific interface to another interface. In typical usage, the listening device is an IDS scanner and it listens for suspicious traffic. In the case of DoD//NSA, they do this at several key routing points on the global Internet and instead of IDS, they use intercept boxes that copy and forward anything of interest. Encrypted traffic goes off to their datacentres for decryption.

    Basically invisible, and doesn't affect traffic at all.
  • 0 in reply to TheDrew
    Duogga,

    If you are seeing a DoD IP Address tied to a MAC in your logs, I doubt it's actually the DoD.

    I've heard of instances (may have been referenced on this forum) where smaller Cell Carriers and/or ISP's, needing Carrier Grade NAT(CGN) either due to inability or unwillingness to purchase netblocks from IANA and not wanting to use the traditional 10.0.0.0/8, have resorted to 'borrowing' various /8 subnets that are they're reasonably confident aren't in use globally, such as the DoD.

    I think in this forum some people noticed one Cell provider using IP's assigned to the UK's version of the DoD. That you're seeing a MAC address of hardware from a company specializing in last mile ATM/TDM/Cell access devices, I wonder if perhaps your cell carrier is using CGN in combo with a borrowed netblock?

    From what I understand about DoD and NSA practices regarding electronic tapping, the taps used are virtually invisible as they aren't "in the way" so to speak. The technique they use is similar to port mirroring on higher end switches. Port Mirroing on a switch basically sends a copy of all traffic on a specific interface to another interface. In typical usage, the listening device is an IDS scanner and it listens for suspicious traffic. In the case of DoD//NSA, they do this at several key routing points on the global Internet and instead of IDS, they use intercept boxes that copy and forward anything of interest. Encrypted traffic goes off to their datacentres for decryption.

    Basically invisible, and doesn't affect traffic at all.


    I agree with the above.  If the .gov is tapping your traffic, you certainly won't "see" them [:)]
  • 0 in reply to BrucekConvergent
    We have data.  I'd like to understand what it means.  Using DoD addresses inside a private address space is not completely irrational, particularly since you have DoD assets now residing within most major telecom datacenters.  This addressing might be an amusing scheme by NetOps and/or a defensive legal manoeuvre to allow internal resources to know when traffic was passing between corporate and government assets.
    [URL="http://www.astaro.org/gateway-products/vpn-site-site-remote-access/47739-when-will-utm-update-current-strongswan-build.html"]
    Seriously, I really appreciate everyone's input.  [I can't change formatting... grrrrr]
    [/URL]
  • 0 in reply to TheDrew
    That makes a lot of sense.
    The one things that doesn't is the foreign/unknown MAC address being seen by the UTM.  This means there's either hardware on my physical network that I don't recognise, or someone's tunnelling the Ethernet protocol.  I need to have another look around.  My switch captures all MAC addresses so I'll peek there - I should be able to see on which ports MAC addresses are seen.
  • 0
    The questions I'd ask are.

    1) What is the public IP address of your phone? I could care less what the exact IP is, more does it match to the suspected DoD IP block? In the case of the CG NAT'd systems, the phone's public IP was a DoD address.

    2) Do you facebook from your phone?

    On the surface of it, my immediate thought is that if your Cell Provider's network uses a DoD address, it's not outside the realm of posibility that your phone L2TP client is trying reach facebook and the like over the L2TP connection but the UTM doesn't like that so is rejecting the traffic.
  • 0 in reply to TheDrew
    I thought I had checked this as a first step.  I think I noticed the encapsulated ip address but overlooked the underlying network addr.

    Looking at ip setup... wow.  Ok, here are the listed interfaces before vpn connection.

    State 1 of 3 WiFi ON:
    1. lo
    2. dummy0   state down
    3. rmnet0 <> state down
    4. rmnet1 <> state down
    5. rmnet2 <> state down
    6. rmnet3 <> state down
    7. rmnet4 <> state down
    8. rmnet5 <> state down
    9. rmnet6 <> state down
    10. rmnet7 <> state down
    11. rev_rmnet0 ... state down...10. rmnet7 <> state down
    12. rev_rmnet1 ... state down...10. rmnet7 <> state down
    13. rev_rmnet2 ... state down...10. rmnet7 <> state down
    14. rev_rmnet3 ... state down...10. rmnet7 <> state down
    15. rev_rmnet4 ... state down...10. rmnet7 <> state down
    16. rev_rmnet5 ... state down...10. rmnet7 <> state down
    17. rev_rmnet6 ... state down...10. rmnet7 <> state down
    18. rev_rmnet7 ... state down...10. rmnet7 <> state down
    19. rev_rmnet8 ... state down...10. rmnet7 <> state down
    20 sit0  state down
    23 p2p0  mtu 1500 state DORMANT link 5e:0a:5b:4e:49[:D]9 inet6 [a valid ip6 address]...
    24. wlan0 ... state up... [my local 10.x.y.z address]


    State 2 of 3:  WiFi off no VPN

    1. lo ... state UNKNOWN...
    2. dummy0   state down
    3. rmnet0  ...state UNKNOWN... inet 21.197.35.144/30
    This is a legacy DoD address and the same class A my logs were throwing earlier that caused me indigestion.
    5. rmnet2 <> state down
    6. rmnet3 <> state down
    7. rmnet4 <> state down
    8. rmnet5 <> state down
    9. rmnet6 <> state down
    10. rmnet7 <> state down
    11. rev_rmnet0 ... state down...10. rmnet7 <> state down
    12. rev_rmnet1 ... state down...10. rmnet7 <> state down
    13. rev_rmnet2 ... state down...10. rmnet7 <> state down
    14. rev_rmnet3 ... state down...10. rmnet7 <> state down
    15. rev_rmnet4 ... state down...10. rmnet7 <> state down
    16. rev_rmnet5 ... state down...10. rmnet7 <> state down
    17. rev_rmnet6 ... state down...10. rmnet7 <> state down
    18. rev_rmnet7 ... state down...10. rmnet7 <> state down
    19. rev_rmnet8 ... state down...10. rmnet7 <> state down
    20 sit0  state down



    State 3 of 3:  above but with L2TP VPN enabled
    1. lo ... state UNKNOWN...
    2. dummy0   state down
    3. rmnet0  ...state UNKNOWN... inet 21.197.35.144/30
    4. rmnet2 <> state down
    5. rmnet2 <> state down
    6. rmnet3 <> state down
    7. rmnet4 <> state down
    8. rmnet5 <> state down
    9. rmnet6 <> state down
    10. rmnet7 <> state down
    11. rev_rmnet0 ... state down...10. rmnet7 <> state down
    12. rev_rmnet1 ... state down...10. rmnet7 <> state down
    13. rev_rmnet2 ... state down...10. rmnet7 <> state down
    14. rev_rmnet3 ... state down...10. rmnet7 <> state down
    15. rev_rmnet4 ... state down...10. rmnet7 <> state down
    16. rev_rmnet5 ... state down...10. rmnet7 <> state down
    17. rev_rmnet6 ... state down...10. rmnet7 <> state down
    18. rev_rmnet7 ... state down...10. rmnet7 <> state down
    19. rev_rmnet8 ... state down...10. rmnet7 <> state down
    20. sit0  state down
    25. ppp0  inet 10.242.3.2 This is my vpn pooled address.

    This is embarassing.
    It was just my Sprint cell ip address all along.

    If I can, I'll delete this thread.  ughhh.