Hello,
I am trying to explain myself the “input” traffic to our company router but stuck in one of the SSTP-out connections:
Here is the scenario (see figure):
LAN1 communicates by means of established tcp connection over VPN with LAN2:someport. The route from LAN1 to LAN2 is through VPN2.
R1 logs “input” chain.
And here are my thoughts about the communication - are they correct or not?:
1.WAN1 establishes VPN connection with WAN2. During this process there is only “output” and “input” traffic from/to both routers, no “forward”.
2.According to the picture and scenario LAN1 becomes masqueraded as VPN1. Thus, communication LAN1-LAN2 is seen in R2 as VPN1-LAN2.
I was expecting that after establishing the VPN, there would be only “forward” traffic in both routers, however an extensive “input” is observed in R1 from WAN2 to WAN1, why?
“input” traffic is traffic towards the router itself. In VPN usage, that is the “outer” traffic of the VPN.
“forward” traffic is traffic the router forwards from interface to interface, in a VPN that would be the “inner” traffic of the tunnel.
Based on your diagram the packets are flowing like this (which is the expected route).
LAN1 (via input chain) → R1 (to cpu) → VPN1 (via R1 output) → WAN1 → traverse the global net → WAN2 → VPN2 (via input chain of R2) → R2 (to cpu) → LAN2 (via output chain of R2).
Packet flows from LAN1 to R1 via the input chain of R1.
Packet is processed in the CPU of R1. (VPN1 encryption step)
Packet is routed out of R1 into WAN1 interface via the output chain of R1.
Packet passes through the tunnel. (Traverses WAN1 → WAN2 through the established tunnel VPN1 → VPN2).
Packet is recieved on the input chain of R2 coming out of WAN2.
Packet is processed in the CPU of R2. (VPN2 decryption step)
Packet is routed out of R2 to the final destination LAN2 via the output chain of R2.
Notes:
In step 3 it is not forwarded because the encrypted packet is generated by the router, forwarding only applies to packets passing through the router.
In step 4, the router is still sending packets via the output chain into the WAN1 interface since VPN1 technically exists in/on the router and is more of a virtual interface that is just encrypting the packet.
Thank you very much blacksnow for the thorough explanation, especially for the useful notes! I, indeed, haven’t thought in that aspect - the added value (encryption) by the CPU to the packets, but rather was focused just on their relaying. So, to conclude: in input chain come one packets, and from output chain are going out different packets (containing first ones).
The return packets from R2 to R1 obviously go through the same processing and I observe them in encrypted state in R1 input. If I want to see the unencrypted packets returned to LAN1, I should rather look at the R1 output chain.
Having the just explained packet flow in mind how about the masquerading in my case? I would expected it to be like this: LAN1->VPN1->WAN1. However, in connection tracking of R2 it is represented as VPN1-LAN2 instead of WAN1-LAN2 ?
In the light of blacksnow explanation, I took another look to the Mikrotik packet flow diagram (PFD) at https://wiki.mikrotik.com/wiki/Manual:Packet_Flow
And realized that outgoing traffic from R1 is passing twice through output chain - once before encapsulation and then after it again.
Rearranging and adjusting the simplified flow lead me to the following:
LAN1 -> (input) R1 (routing decision VPN through WAN1) (cpu) (output unencrypted) (masquerade unencrypted as WAN1) (encrypt/encapsulate) (output encrypted) (masquerade encrypted as VPN1) -> traverse the global net -> WAN2 -> (input encrypted) R2 (prerouting) (routing decision to LAN2) (decapsulate) (input decrypted) (cpu) (output) -> LAN2.
Connection tracking appears twice in PFD: in prerouting phase and in output. May be the connection VPN1-LAN2 I observe in R2 is in prerouting phase when the routing decision is not yet performed.
Note: Used encrypt and encapsulate as synonyms, realizing the difference.
