0

For an end-to-site VPN, i.e. where a device (VPN client) is responsible for encapsulating the GRE packet, is it possible to send some custom data along with the GRE packet beyond just the standard payload.

Take for example a GRE packet assembled by a VPN client:

| IP header | GRE Header | Standard Payload |

Such that the Standard Payload looked like:

|Orignal IP Header| Orignal Payload|

In theory, if I wanted to append some extra data (Custom Data), such as some identifier of the VPN Client beyond an IP address to a GRE Packet payload, such that the packet then looked like:

|IP header| GRE Header | Custom Data + Standard Payload|

Would that be possible?

It seems if there was a way to access wherever the original packet is encapsulated into a GRE packet, you could make that payload whatever you desired, assuming the VPN server knew to strip off the Custom Data section of the payload.

Essentially, is there a way to add some custom data per packet to the payload or some place in the header for a given request. If so, at what level or where would this need to take place?

Improve this question
4
  • 2
    No. It would take a custom protocol that is off-topic here.
    – Ron Maupin ♦
    Jun 15, 2018 at 18:35
  • A custom protocol, sure, in the sense that the VPN client and VPN server would both need to know about a designated custom section of the payload, but it would seem to me you could still use IP to accomplish it.
    – cg14
    Jun 15, 2018 at 18:42
  • "but it would seem to me you could still use IP to accomplish it." No, IP knows nothing about such things. IP is very well defined, and it includes nothing that allows this.
    – Ron Maupin ♦
    Jun 15, 2018 at 18:44
  • Your custom protocol is off-topic here, as is your server. VPNs are on-topic as configured for on-topic network equipment (e.g routers), but host/server/VM configurations are off-topic, as are hypothetical protocols.
    – Ron Maupin ♦
    Jun 15, 2018 at 18:47

1 Answer 1

Reset to default
1

In theory, the tunneling protocol would need to be modified to include the option for a "side channel".

However, what would be accomplished? The absolute same could be achieved using a separate IP connection (perhaps UDP) that is simply routed through the tunnel along with the other user packets. This has the added benefit of allowing a connection from one end of the network across the tunnel to the other end instead of just from one tunnel end to the other.

If you're trying to add an application-layer protocol ("header", "request") to a tunnel protocol you've forgotten that network layering serves a purpose.

So, to answer your question: possible? yes, by defining a protocol supporting this - practical? no.

Improve this answer
2
  • I thought about it some more. If you were to use the payload section to add a tag to every packet, you would have to remap the entirety of the request, probably ending up with more packets than you originally started with, so as to keep your MTU something routers are capable of handling. A better solution would be to use the optional key field on the GRE header. If you disable the key, then effectively the router or VPS should ignore the key field, and you can have 32 bits to work with.Obviously this puts limitations on what data you can send, and may "break" the intended use, but it'd "work"?
    – cg14
    Jun 15, 2018 at 19:55
  • Better in the sense that, while you would loose being able to send "larger" data fields, you wouldn't have to have the performance lose of remapping the entirety of the request (if all OS api's would even allow this) and you could still send some "extra" data.
    – cg14
    Jun 15, 2018 at 20:03

Not the answer you're looking for? Browse other questions tagged or ask your own question.