Hi, not sure where to post this, I can’t find a similar thread with the search function.
I’m having a problem with the DHCP Server and using L2TP tunnel on a CCR running 6.1, I’ve tried 6.0 and it does the same thing. It seems the DHCP responses are modified when they are sent out through the tunnel, an additional header seems to be added to the beginning of the packet. This does not happen when the same packet goes out on an ethernet interface.
I’ve tried the same setup on an RB2011 running 5.25, and there it works fine.
I tried using the sniffer and checking the dump in wireshark.
Here’s what /tool sniffer quick gives me for the used interfaces, you see the request entering and a corrupted packet exiting as answer.
INTERFACE TIME NUM DIR SRC-MAC DST-MAC VLAN SRC-ADDRESS DST-ADDRESS PROTOCOL SIZE
l2tp-J... 1.4 1 <- 0.0.0.0:68 (bootpc) 255.255.255.255:67 (bootps) ip:udp 328
br_hot... 1.4 2 <- D4:CA:6D:40:2A:2E FF:FF:FF:FF:FF:FF 0.0.0.0:68 (bootpc) 255.255.255.255:67 (bootps) ip:udp 342
br_hot... 1.401 4 -> D4:CA:6D:AC:B8:A5 FF:FF:FF:FF:FF:FF 10.112.0.3:67 (bootps) 255.255.255.255:68 (bootpc) ip:udp 342
l2tp-J... 1.401 3 -> 8.0.69.0 1.72.0.0 ip:172 342
the packet seems to be fine as long as it remains on the bridge (or exits on an ethernet interface with a connected pc), but on the l2tp interface it suddenly looks corrupted, with weird src and dst addresses. It also never makes it to the other end of the tunnel, the sniffer on the client shows no response at all.
As I said, when I try the exact same setup on an RB2011 running v5.25 it works fine in the tunnel as well.
Here’s the raw data from the packet sniffer on the bridge interface:
0000: ff ff ff ff ff ff d4 ca 6d ac b8 a5 08 00 45 00 ........ m.....E.
0010: 01 48 00 00 00 00 10 11 9f 33 0a 70 00 03 ff ff .H...... .3.p....
0020: ff ff 00 43 00 44 01 34 55 db 02 01 06 00 7c e8 ...C.D.4 U.....|.
0030: 9d dc 00 00 80 00 00 00 00 00 0a 71 ff ff 0a 70 ........ ...q...p
0040: 00 03 00 00 00 00 d4 ca 6d 40 2a 2e 00 00 00 00 ........ m@*.....
0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
0100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
0110: 00 00 00 00 00 00 63 82 53 63 35 01 02 36 04 0a ......c. Sc5..6..
0120: 70 00 03 33 04 00 00 0e 10 01 04 ff f8 00 00 03 p..3.... ........
0130: 04 0a 70 00 03 06 0c 0a 70 00 03 50 5a 2d 43 50 ..p..... p..PZ-CP
0140: 5a 2c 19 2a 04 32 1f f0 d6 ff 00 00 00 00 00 00 Z,.*.2.. ........
0150: 00 00 00 00 00 00 ......
And this is what ends up in the dump from the l2tp interface, as wireshark shows it.
On the packet sniffer it shows up exactly the same as above, but with
Src. Address 8.0.69.0
Src. Port
Dst. Address 1.72.0.0
Dst. Port
0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 ff ff ........ ........
0010 ff ff ff ff d4 ca 6d ac b8 a5 08 00 45 00 01 48 ......m. ....E..H
0020 00 00 00 00 10 11 9f 33 0a 70 00 03 ff ff ff ff .......3 .p......
0030 00 43 00 44 01 34 5a c8 02 01 06 00 06 9e 0f 3a .C.D.4Z. .......:
0040 00 00 80 00 00 00 00 00 0a 71 ff ff 0a 70 00 03 ........ .q...p..
0050 00 00 00 00 d4 ca 6d 40 2a 2e 00 00 00 00 00 00 ......m@ *.......
0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
0110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
0120 00 00 00 00 63 82 53 63 35 01 02 36 04 0a 70 00 ....c.Sc 5..6..p.
0130 03 33 04 00 00 0e 10 01 04 ff f8 00 00 03 04 0a .3...... ........
0140 70 00 03 06 0c 0a 70 00 03 50 5a 2d 43 50 5a 2c p.....p. .PZ-CPZ,
0150 19 2a 04 32 1f f0 d6 ff 00 00 00 00 00 00 00 00 .*.2.... ........
0160 00 00 00 00
You can see an additional Ethernet II header seems to be added, with src and dst of 00:00:00:00:00:00.
I’ve tried a downgrade to 6.0, factory reset, I even tried the setup on a new CCR out of the box with only the necessary setup, it always gives me these responses.
However, if I connect another DHCP server via another L2TP link and disable the built in Server the packets from the other server go through fine (through both tunnels), so it only affects the built-in DHCP server.
How do I stop the CCR from adding this additional header?
Thanks 