Mangle packets over PPTP/GRE

Hello.

I’m using RB150 (routeros 3.0rc6) device to route traffic between several LAN’s and adsl modem (btw many thanks to developers for implementing “switch” functionality :slight_smile:.
Everything works pretty good, however I’ve got problem trying to mark specific (for example some kind of UDP) VPN (usual PPTP, visible as GRE in sniffer) packets with mangle facility.

/ip firewall mangle add chain=prerouting action=accept protocol=udp

doesn’t matches any packets (that’s ok, first protocol header comming after IP is GRE). Ok, then I tried to match all pptp packets, that works:

/ip firewall mangle add chain=prerouting action=accept connection-type=pptp

That rule successfully catches all pptp packets flowing thru the router, however at this time I’ve found no posibility to filter only UDP (for example) packets from them, for example combined rule again misses all the (here comes a list of protocols/headers in a packet) Ethernet/IP/GRE/UDP packets:

/ip firewall mangle add chain=prerouting action=accept protocol=udp connection-type=pptp

Any ideas? :slight_smile:

p.s. VPN tunnels are from client side (Windows computers) to the provider (thru adsl).

wbr, Nik.

that is the answer. VPN is secure connection, it encapsulates all user’s traffic and hides it from any kind of sniffing. so the router see only GRE connection, and cannot get a look inside

Actually secure/non-secure is controlled by VPN tunnel settings, and our provider (Atlant-telecom, you should know him :slight_smile: prohibits encryption). I’ve added the sample packet dump below. I don’t want a general solution, just thought there should be resolution in my case, when the actual packet is going after GRE header.

Offtopic: have you found any mikrotik dealers in belarus? :slight_smile:

Packet #1, Direction: Out, Time:13:47:42.647979, Size: 102
Ethernet II
Destination MAC: 00:0C:42:12:14:05
Source MAC: 00:11:2F:42:D5:29
Ethertype: 0x0800 (2048) - IP
IP
IP version: 0x04 (4)
Header length: 0x05 (5) - 20 bytes
Type of service: 0x00 (0)
Precedence: 000 - Routine
Delay: 0 - Normal delay
Throughput: 0 - Normal throughput
Reliability: 0 - Normal reliability
Total length: 0x0058 (88)
ID: 0x34F2 (13554)
Flags
Don’t fragment bit: 0 - May fragment
More fragments bit: 0 - Last fragment
Fragment offset: 0x0000 (0)
Time to live: 0x80 (128)
Protocol: 0x2F (47) - GRE
Checksum: 0x06C3 (1731) - correct
Source IP: 192.168.2.24
Destination IP: 10.1.50.1
IP Options: None
GRE
Payload present: 0x01 (1)
Protocol: 0x880B (34827)
Payload length: 0x0038 (56)
Call ID: 0xB1C7 (45511)
Sequence number: 0x00000025 (37)
Protocol: 0x0021 (33) - IPv4
IP
IP version: 0x04 (4)
Header length: 0x05 (5) - 20 bytes
Type of service: 0x00 (0)
Precedence: 000 - Routine
Delay: 0 - Normal delay
Throughput: 0 - Normal throughput
Reliability: 0 - Normal reliability
Total length: 0x0034 (52)
ID: 0x34F1 (13553)
Flags
Don’t fragment bit: 0 - May fragment
More fragments bit: 0 - Last fragment
Fragment offset: 0x0000 (0)
Time to live: 0x80 (128)
Protocol: 0x11 (17) - UDP
Checksum: 0x6E5B (28251) - correct
Source IP: 10.128.6.203
Destination IP: 194.158.195.131
IP Options: None
UDP
Source port: 1114
Destination port: 53
Length: 0x0020 (32)
Checksum: 0xE0B2 (57522) - correct
DNS
ID: 0x2CC5 (11461)
Response packet: 0
Operation code: 0x00 (0) - Standard query
Flags
Authoritative Answer: 0
Truncation: 0
Recursion Desired: 1
Recursion Available: 0
Question records: 0x0001 (1)
Answer records: 0x0000 (0)
Authority records: 0x0000 (0)
Additional records: 0x0000 (0)
Question section
Record: 0x1 (1)
Name: brains
Type: 0x0006 (6) - SOA
Class: 0x0001 (1) - IN

hmmm… even if you try using packet content in firewall, i don’t think, that GRE will normally react to GRE packets dropping or slowing down by queues…

I bought license at MikroTik, not resellers

It seems it just captures all the packets containing gre header, because when I activate the rule with connectiontype=gre it immideatly matches packets flow from old PPTP sessions.

Buying license is easy, but I couldn’t say that about hardware… :slight_smile: I’ve bought 2 RB150 during my trip to poland, but I don’t know were to get some more now (the nearest places are Moscow and Kiev)…

you most likely use GRE NAT helper, it marks all gre connections with connectiontype=gre, that is why you get these results

well, what do you like to do with GRE-encapsulated UDP traffic?

Hm, don’t know what the “GRE NAT helper” mean, haven’t seen in options/docs anything like that :slight_smile: There are no NAT / other Mangle rules defined (if you mean something like that).

Apply some marks for the beginning :slight_smile: Basically it was the proof of concept, however I thought about getting statistics for different kind of traffic and (maybe) setting priorities.

Firewall → Service Ports → gre

Yes, pptp service port is turned on (i’ve got no gre here, and also got no connection-type=gre, just pptp, but it works like described before). However that doesn’t matter that much. This way or that way I could match GRE traffic, but I couldn’t match/analyse encapsulated packet itself, even if it is unecrypted/uncompressed. That is the point of interest :slight_smile: