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?

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 BarryG over 11 years ago

Hi,

1. please post entries from the full log, not the live log

2. I'm assuming the 'l2tp' entry in the live log refers to the virtual interface, but I'm not certain.
What is your firewall rule #6?

3. can you double-check what is the IP of the phone's VPN client connection? Maybe it is using the 21.194.27.36 IP address for some reason.

Barry
Cancel
Vote Up 0 Vote Down

Cancel

0 SalishSwede over 11 years ago in reply to BarryG

1. Entries from the full log


2013:12:04-14:08:16 ravenna ulogd[4818]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="6" initf="ppp1" outitf="ppp0" mark="0x3106" app="262" srcmac="0:0:2f[:D]2:32:f7" srcip="21.194.27.36" dstip="50.115.125.93" proto="6" length="40" tos="0x00" prec="0x00" ttl="63" srcport="39669" dstport="443" tcpflags="RST"  

2013:12:04-14:08:19 ravenna ulogd[4818]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="6" initf="ppp1" outitf="ppp0" mark="0x3106" app="262" srcmac="0:0:2f[:D]2:32:f7" srcip="21.194.27.36" dstip="50.115.125.93" proto="6" length="40" tos="0x00" prec="0x00" ttl="63" srcport="39669" dstport="443" tcpflags="RST"  

2013:12:04-14:08:19 ravenna ulogd[4818]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="6" initf="ppp1" outitf="ppp0" mark="0x3106" app="262" srcmac="0:0:2f[:D]2:32:f7" srcip="21.194.27.36" dstip="69.171.245.49" proto="6" length="130" tos="0x00" prec="0x00" ttl="63" srcport="38247" dstport="443" tcpflags="ACK PSH"  

2013:12:04-14:08:26 ravenna ulogd[4818]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="6" initf="ppp1" outitf="ppp0" mark="0x3106" app="262" srcmac="0:0:2f[:D]2:32:f7" srcip="21.194.27.36" dstip="50.115.125.93" proto="6" length="40" tos="0x00" prec="0x00" ttl="63" srcport="39669" dstport="443" tcpflags="RST"

2a. Yes, I was thinking just that: that the L2TP referred to the v-interface.
2b.  Firewall rule 6 was just a late night amusement I threw in a few weeks ago.
     I went to the IANA site and created a definition which includes all registered Dept. of Defense addresses (mostly class A networks)
     I then created a rule, dropping all traffic coming from those addresses.
     I had probably had a beer [breaking my rule of no alcohol while fiddling with firewalls] so I overlooked traffic coming from the DoD.

3.  The phone's VPN IP is as follows per Web Admin
  username  FIRST LAST 10.242.3.2

0 SalishSwede over 11 years ago in reply to SalishSwede

My oversight may have created the hook allowing the view to the traffic.
Cancel
Vote Up 0 Vote Down

Cancel
0 SalishSwede over 11 years ago in reply to SalishSwede

I'm very curious if you can recreate this. This may be a global infiltration of a more vulnerable VPN protocol. In which case, Sophos should remove support for this protocol (unless Sophos is in bed with the DoD, of course).
Cancel
Vote Up 0 Vote Down

Cancel
0 SalishSwede over 11 years ago in reply to SalishSwede

I've attached screenshots of the rule blocking DoD traffic.
Anyone can recreate exactly what I've done to see if they can see similar traffic.
Please post to this thread any results positive or negative.

Instructions:
1. Create a network group and add all DOD-related address spaces per attached images.  [better to recreate exactly what I've done]
Note: This is the source of my rule-set:
IANA IPv4 Address Space Registry
2. Create a firewall rule dropping all traffic going TO [not from] this network group.  Make sure to log traffic as part of the rule.
    Note: It's possible that the failure to drop traffic from is what allows the firewall to see any of the traffic at all.
3. Setup an L2TP interface under Remote Access
4. Setup an L2TP connection on a smartphone.  I am using a CyanogenMod derrivative of Android.  It's possible that CyanogenMod is the source of the trouble [possible infiltration?].
5. If you're local to your UTM and on wifi, turn off Wifi so you're using your phone company for internet access to your smartphone.
6. Connect your smartphone via L2TP
6a. To troubleshoot L2TP connections see the UTM log titled "IPSec VPN"
7. Watch the firewall logs for hits on the new Department of Defense rule.

DOD1.png

DOD2.png

DOD_Addresses.png
- DOD1.png
- View
- Hide
Cancel
Vote Up 0 Vote Down

Cancel
0 BarryG over 11 years ago

Hi,

initf="ppp1" outitf="ppp0"

1. Is ppp1 your L2TP VPN, and is ppp0 a PPPoE DSL Internet connection?

2. do you have WiFi Tethering or anything like that enabled on the phone?
If so, what IP addresses is it handing out?

3. try running
route -n
on the UTM while the phone is connected to the VPN

4. try a traceroute to that IP address while the phone is connected and disconnected

If I'm backwards about #1 above, then it's possible your http proxy in the UTM is listening on the internet interface. Double-check it and the SOCKS proxy and the Generic Proxy and all your NATs.

Barry
Cancel
Vote Up 0 Vote Down

Cancel
0 BarryG over 11 years ago

Hi,
The MAC address in the logs is registered to TimePlex Inc.
MAC_Find: Search results for "00:00:2f[:D]2:32:f7" (Vendor/Ethernet/Bluetooth MAC Address Lookup and Search)

Is that your modem/router or phone or one of the UTM's NICs or something else?

Barry
Cancel
Vote Up 0 Vote Down

Cancel
0 BarryG over 11 years ago

OT:
1. you have the 33.0.0.0/8 definition defined twice

2. to be complete, you should have another definition dropping traffic TO those addresses

Barry
Cancel
Vote Up 0 Vote Down

Cancel

0 SalishSwede over 11 years ago in reply to BarryG

>>Hi,

>>initf="ppp1" outitf="ppp0"

>>1. Is ppp1 your L2TP VPN, and is ppp0 a PPPoE DSL Internet connection?

Yes and Yes.
Here's the routing table:

[note: public ip addresses changed for security reasons]
[a.b.c.d & w.x.y.z are used instead of real addresses]


default via a.b.c.d dev ppp0  table 200  proto kernel onlink
local default dev lo  table 252  scope host  
default via a.b.c.d dev ppp0  table default  proto kernel  metric 20 onlink
10.1.0.0/16 dev eth0  proto kernel  scope link  src 10.1.1.2  
10.3.0.0/16 dev eth4  proto kernel  scope link  src 10.3.0.1  
10.242.3.2 dev ppp1  proto kernel  scope link  src 10.242.3.1  
w.x.y.z dev ppp0  proto kernel  scope link  src a.b.c.d  [changed for privacy]  
127.0.0.0/8 dev lo  scope link  
172.16.0.0/12 dev eth3  proto kernel  scope link  src 172.16.0.1  
broadcast 10.1.0.0 dev eth0  table local  proto kernel  scope link  src 10.1.1.2  
local 10.1.1.2 dev eth0  table local  proto kernel  scope host  src 10.1.1.2  
broadcast 10.1.255.255 dev eth0  table local  proto kernel  scope link  src 10.1.1.2
  broadcast 10.3.0.0 dev eth4  table local  proto kernel  scope link  src 10.3.0.1
  local 10.3.0.1 dev eth4  table local  proto kernel  scope host  src 10.3.0.1
  broadcast 10.3.255.255 dev eth4  table local  proto kernel  scope link  src 10.3.0.1
  local 10.242.3.1 dev ppp1  table local  proto kernel  scope host  src 10.242.3.1  
local w.x.y.z dev ppp0  table local  proto kernel  scope host  src a.b.c.d
 broadcast 127.0.0.0 dev lo  table local  proto kernel  scope link  src 127.0.0.1 
 local 127.0.0.0/8 dev lo  table local  proto kernel  scope host  src 127.0.0.1  
local 127.0.0.1 dev lo  table local  proto kernel  scope host  src 127.0.0.1  
broadcast 127.255.255.255 dev lo  table local  proto kernel  scope link  src 127.0.0.1 
 broadcast 172.16.0.0 dev eth3  table local  proto kernel  scope link  src 172.16.0.1 
 local 172.16.0.1 dev eth3  table local  proto kernel  scope host  src 172.16.0.1 
 broadcast 172.31.255.255 dev eth3  table local  proto kernel  scope link  src 172.16.0.1  
unreachable default dev lo  table unspec  proto kernel  metric 4294967295  error -101
 unreachable default dev lo  table unspec  proto kernel  metric 4294967295  error -101
 local ::1 via :: dev lo  table local  proto none  metric 0  
unreachable default dev lo  table unspec  proto kernel  metric 4294967295 error-101

>>2. do you have WiFi Tethering or anything like that enabled on the phone?
>>If so, what IP addresses is it handing out?

There is no wifi tethering enabled. I have a standard connection to the phone company and a L2TP VPN enabled.

>>3. try running route -n on the UTM while the phone is connected to the VPN
Results:

ravenna:/home/login # route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.1.0.0        0.0.0.0         255.255.0.0     U     0      0        0 eth0
10.3.0.0        0.0.0.0         255.255.0.0     U     0      0        0 eth4
10.242.3.2      0.0.0.0         255.255.255.255 UH    0      0        0 ppp1
w.x.y.z[pravacy!]          0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
172.16.0.0      0.0.0.0         255.240.0.0     U     0      0        0 eth3

>>4. try a traceroute to that IP address while the phone is connected and disconnected

Connected:

traceroute to 10.242.3.2 (10.242.3.2), 30 hops max, 40 byte packets using UDP
 1  10.242.3.2 (10.242.3.2)  104.791 ms   133.877 ms   138.922 ms

Disconnected:

ravenna:/home/login # traceroute 10.242.3.2
traceroute to 10.242.3.2 (10.242.3.2), 30 hops max, 40 byte packets using UDP
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *

Given this address is a non-routable public address, shouldn't this have failed?

>>If I'm backwards about #1 above, then it's possible your http proxy in the UTM is >>listening on the internet interface. Double-check it and the SOCKS proxy and the >>Generic Proxy and all your NATs.

Socks proxy is off. Checking Web Protection > Web Filtering > Global > Allowed Networks, I have the following allowed:
Corporate Network
Internal Network [my primary net]
The VPN pools had a firewall rule allowing outbound traffic... I'm changing this.

0 SalishSwede over 11 years ago in reply to BarryG
Here's the interface table of the UTM  hint: it's not in there.

1: lo:  mtu 65536 qdisc noqueue state UNKNOWN      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00     inet 127.0.0.1/8 scope host lo     inet6 ::1/128 scope host         valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc hfsc state UNKNOWN qlen 1000     link/ether 00:0c:29:f2:87:19 brd ff:ff:ff:ff:ff:ff     inet 10.1.1.2/16 brd 10.1.255.255 scope global eth0
3: eth1:  mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000     link/ether 00:0c:29:f2:87:23 brd ff:ff:ff:ff:ff:ff
4: eth2:  mtu 1500 qdisc noop state DOWN qlen 1000     link/ether 00:0c:29:f2:87:2d brd ff:ff:ff:ff:ff:ff
5: eth3:  mtu 1500 qdisc pfifo_fast state UP qlen 1000     link/ether 00:0c:29:f2:87:37 brd ff:ff:ff:ff:ff:ff     inet 172.16.0.1/12 brd 172.31.255.255 scope global eth3
6: eth4:  mtu 1500 qdisc pfifo_fast state UP qlen 1000     link/ether 00:0c:29:f2:87:41 brd ff:ff:ff:ff:ff:ff     inet 10.3.0.1/16 brd 10.3.255.255 scope global eth4
13: ppp0:  mtu 1492 qdisc hfsc state UNKNOWN qlen 3     link/ppp      inet 71.212.26.3 peer 63.231.10.254/32 scope global ppp0 15: ifb0:  mtu 1500 qdisc tbf state UNKNOWN qlen 32     link/ether 5a:63:63:0a:94:9c brd ff:ff:ff:ff:ff:ff

There are no current dynamic DHCP leases.
This MAC is not found in the static address table.
Since this is a MAC address from a device from a DoD address, I wouldn't expect it to be found locally but I have done the due-diligence anyway.

From the Timeplex web site:
[SIZE=2]As TimePlex, we provide
[/SIZE]

[FONT=Arial][SIZE=2]Networking Products -- [/SIZE][/FONT][FONT=Arial][SIZE=1]you can count on[/SIZE][/FONT][FONT=Arial][SIZE=1]
[/SIZE][/FONT]

[FONT=Arial][SIZE=2]ATM (
[/SIZE][/FONT][FONT=Arial][SIZE=2]Timeplex [/SIZE][/FONT][FONT=Arial][SIZE=2]Cell Exchange)[/SIZE][/FONT][FONT=Arial][SIZE=2]
[/SIZE][/FONT]
[FONT=Arial][SIZE=2]TDM and compressed voice products (
[/SIZE][/FONT][FONT=Arial][SIZE=2]Timeplex [/SIZE][/FONT][FONT=Arial][SIZE=2]Link/2
[/SIZE][/FONT][FONT=Arial][SIZE=2]and [/SIZE][/FONT][FONT=Arial][SIZE=2]Timeplex [/SIZE][/FONT][FONT=Arial][SIZE=2]Synchrony ST-[/SIZE][/FONT][FONT=Arial][SIZE=2]1000)[/SIZE][/FONT][FONT=Arial][SIZE=2]
[/SIZE][/FONT]
[FONT=Arial][SIZE=2]Frame Relay including VoFR (Synchrony ST-1000)
[/SIZE][/FONT][FONT=Arial][SIZE=2]
[/SIZE][/FONT]
[FONT=Arial][SIZE=2]Network Management (TimeView and SNMS)
[/SIZE][/FONT][FONT=Arial][SIZE=2]
[/SIZE][/FONT]

[FONT=Arial][SIZE=2]Services -- [/SIZE][/FONT][FONT=Arial][SIZE=1]we care [/SIZE][/FONT][FONT=Arial][SIZE=1]for [/SIZE][/FONT][FONT=Arial][SIZE=1]your business[/SIZE][/FONT][FONT=Arial][SIZE=1]
[/SIZE][/FONT]

[FONT=Arial][SIZE=2]Maintenance contract
[/SIZE][/FONT][FONT=Arial][SIZE=2]s[/SIZE][/FONT][FONT=Arial][SIZE=2]
[/SIZE][/FONT]
[FONT=Arial][SIZE=2]Repairing
[/SIZE][/FONT][FONT=Arial][SIZE=2]Timeplex products[/SIZE][/FONT][FONT=Arial][SIZE=2]
[/SIZE][/FONT]
[FONT=Arial][SIZE=2]Migrat
[/SIZE][/FONT][FONT=Arial][SIZE=2]ing[/SIZE][/FONT][FONT=Arial][SIZE=2] network[/SIZE][/FONT][FONT=Arial][SIZE=2]s[/SIZE][/FONT][FONT=Arial][SIZE=2] into ATM for all your customized
[/SIZE][/FONT][FONT=Arial][SIZE=2]networking requirements[/SIZE][/FONT][FONT=Arial][SIZE=2]
[/SIZE][/FONT]
[FONT=Arial][SIZE=2]Training courses for Timeplex products
[/SIZE][/FONT][FONT=Arial][SIZE=2]
[/SIZE][/FONT]

[FONT=Arial][SIZE=2]Manufacturing -- [/SIZE][/FONT][FONT=Arial][SIZE=1]proud [/SIZE][/FONT][FONT=Arial][SIZE=1]to be [/SIZE][/FONT][FONT=Arial][SIZE=1]made in U.S.A.[/SIZE][/FONT][FONT=Arial][SIZE=1]
[/SIZE][/FONT]

[FONT=Arial][SIZE=2]Providing contract manufacturing with high quality and
[/SIZE][/FONT][FONT=Arial][SIZE=2]satisfaction[/SIZE][/FONT]

[SIZE=2][FONT=Arial]
[/FONT][/SIZE]
Cancel
Vote Up 0 Vote Down

Cancel