Packet loss of RDP connection routing via different gateway



  • Hello,

    i'm new to pfSense, so it also could be a mistake on my side, but i couldn't find a solution by myself. Here is my setup:

    
                       Gateway-1
                           |
                          WAN
                           |
    Machine-A    pfSense 2.3-RELEASE    Gateway-2
        |                  |                |
        ================= LAN ===============
    
    

    The default gateway on Machine-A is pfSense. Now if i connect from Machine-A to a system which is behind Gateway-1, everything is fine and works as expected. There are some IP-addresses, which could only be accessed via Gateway-2. So i added a rule which just set the gateway to Gateway-2 for those IP-addresses. Everything is fine, ping runs without interruption. But if i now start an RDP connection, first everything is fine, but after some time (around 20 seconds) i couldn't input anything (mouse doesn't move). Strange thing is, i still see updates (e. g. if task manager is running, i still get updates). After another 20 seconds i get a reconnect message from the RDP client and everything is working fine for another 20 seconds and so on. I then tried to find out, what happens and here are my log entries:

    Machine-A:

    
    11:58:20.370690 IP (tos 0x0, ttl 64, id 13705, offset 0, flags [DF], proto TCP (6), length 169)
        192.168.1.11.36768 > 195.195.195.21.3389: Flags [P.], cksum 0xed83 (correct), seq 66713:66830, ack 76525, win 1354, options [nop,nop,TS val 745556584 ecr 10155549], length 117
    11:58:20.375460 IP (tos 0x0, ttl 64, id 13706, offset 0, flags [DF], proto TCP (6), length 137)
        192.168.1.11.36768 > 195.195.195.21.3389: Flags [P.], cksum 0xb72c (correct), seq 66830:66915, ack 76525, win 1354, options [nop,nop,TS val 745556588 ecr 10155549], length 85
    11:58:20.387772 IP (tos 0x0, ttl 64, id 13707, offset 0, flags [DF], proto TCP (6), length 137)
        192.168.1.11.36768 > 195.195.195.21.3389: Flags [P.], cksum 0x7b14 (correct), seq 66915:67000, ack 76525, win 1354, options [nop,nop,TS val 745556601 ecr 10155549], length 85
    11:58:20.411227 IP (tos 0x0, ttl 64, id 13708, offset 0, flags [DF], proto TCP (6), length 137)
        192.168.1.11.36768 > 195.195.195.21.3389: Flags [P.], cksum 0xaf07 (correct), seq 67000:67085, ack 76525, win 1354, options [nop,nop,TS val 745556624 ecr 10155549], length 85
    11:58:20.412205 IP (tos 0x0, ttl 127, id 6467, offset 0, flags [DF], proto TCP (6), length 52)
        195.195.195.21.3389 > 192.168.1.11.36768: Flags [.], cksum 0x422c (correct), ack 66713, win 64000, options [nop,nop,TS val 10155554 ecr 745556541], length 0
    11:58:20.435114 IP (tos 0x0, ttl 127, id 6468, offset 0, flags [DF], proto TCP (6), length 52)
        195.195.195.21.3389 > 192.168.1.11.36768: Flags [.], cksum 0x41ff (correct), ack 66915, win 63798, options [nop,nop,TS val 10155556 ecr 745556584], length 0
    11:58:20.471622 IP (tos 0x0, ttl 127, id 6469, offset 0, flags [DF], proto TCP (6), length 52)
        195.195.195.21.3389 > 192.168.1.11.36768: Flags [.], cksum 0x41ea (correct), ack 67000, win 63713, options [nop,nop,TS val 10155560 ecr 745556601], length 0
    11:58:20.502562 IP (tos 0x0, ttl 64, id 13709, offset 0, flags [DF], proto TCP (6), length 137)
        192.168.1.11.36768 > 195.195.195.21.3389: Flags [P.], cksum 0x96f1 (correct), seq 67085:67170, ack 76525, win 1354, options [nop,nop,TS val 745556715 ecr 10155560], length 85
    11:58:20.643689 IP (tos 0x0, ttl 64, id 13710, offset 0, flags [DF], proto TCP (6), length 137)
        192.168.1.11.36768 > 195.195.195.21.3389: Flags [P.], cksum 0x1ccb (correct), seq 67170:67255, ack 76525, win 1354, options [nop,nop,TS val 745556857 ecr 10155560], length 85
    11:58:20.687570 IP (tos 0x0, ttl 64, id 13711, offset 0, flags [DF], proto TCP (6), length 137)
        192.168.1.11.36768 > 195.195.195.21.3389: Flags [P.], cksum 0x1c9f (correct), seq 67170:67255, ack 76525, win 1354, options [nop,nop,TS val 745556901 ecr 10155560], length 85
    
    

    pfSense:

    
    11:58:20.374918 00:e0:81:c1:48:e0 > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 183: (tos 0x0, ttl 64, id 13705, offset 0, flags [DF], proto TCP (6), length 169)
        192.168.1.11.36768 > 195.195.195.21.3389: Flags [P.], cksum 0xed83 (correct), seq 66712:66829, ack 76525, win 1354, options [nop,nop,TS val 745556584 ecr 10155549], length 117
    11:58:20.374926 00:16:3e:48:dc:8c > 00:16:3e:23:b1:c4, ethertype IPv4 (0x0800), length 183: (tos 0x0, ttl 64, id 13705, offset 0, flags [DF], proto TCP (6), length 169)
        192.168.1.11.36768 > 195.195.195.21.3389: Flags [P.], cksum 0xed83 (correct), seq 66712:66829, ack 76525, win 1354, options [nop,nop,TS val 745556584 ecr 10155549], length 117
    11:58:20.379687 00:e0:81:c1:48:e0 > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 151: (tos 0x0, ttl 64, id 13706, offset 0, flags [DF], proto TCP (6), length 137)
        192.168.1.11.36768 > 195.195.195.21.3389: Flags [P.], cksum 0xb72c (correct), seq 66829:66914, ack 76525, win 1354, options [nop,nop,TS val 745556588 ecr 10155549], length 85
    11:58:20.379694 00:16:3e:48:dc:8c > 00:16:3e:23:b1:c4, ethertype IPv4 (0x0800), length 151: (tos 0x0, ttl 64, id 13706, offset 0, flags [DF], proto TCP (6), length 137)
        192.168.1.11.36768 > 195.195.195.21.3389: Flags [P.], cksum 0xb72c (correct), seq 66829:66914, ack 76525, win 1354, options [nop,nop,TS val 745556588 ecr 10155549], length 85
    11:58:20.391961 00:e0:81:c1:48:e0 > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 151: (tos 0x0, ttl 64, id 13707, offset 0, flags [DF], proto TCP (6), length 137)
        192.168.1.11.36768 > 195.195.195.21.3389: Flags [P.], cksum 0x7b14 (correct), seq 66914:66999, ack 76525, win 1354, options [nop,nop,TS val 745556601 ecr 10155549], length 85
    11:58:20.391969 00:16:3e:48:dc:8c > 00:16:3e:23:b1:c4, ethertype IPv4 (0x0800), length 151: (tos 0x0, ttl 64, id 13707, offset 0, flags [DF], proto TCP (6), length 137)
        192.168.1.11.36768 > 195.195.195.21.3389: Flags [P.], cksum 0x7b14 (correct), seq 66914:66999, ack 76525, win 1354, options [nop,nop,TS val 745556601 ecr 10155549], length 85
    11:58:20.415460 00:e0:81:c1:48:e0 > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 151: (tos 0x0, ttl 64, id 13708, offset 0, flags [DF], proto TCP (6), length 137)
        192.168.1.11.36768 > 195.195.195.21.3389: Flags [P.], cksum 0xaf07 (correct), seq 66999:67084, ack 76525, win 1354, options [nop,nop,TS val 745556624 ecr 10155549], length 85
    11:58:20.506786 00:e0:81:c1:48:e0 > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 151: (tos 0x0, ttl 64, id 13709, offset 0, flags [DF], proto TCP (6), length 137)
        192.168.1.11.36768 > 195.195.195.21.3389: Flags [P.], cksum 0x96f1 (correct), seq 67084:67169, ack 76525, win 1354, options [nop,nop,TS val 745556715 ecr 10155560], length 85
    11:58:20.647904 00:e0:81:c1:48:e0 > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 151: (tos 0x0, ttl 64, id 13710, offset 0, flags [DF], proto TCP (6), length 137)
        192.168.1.11.36768 > 195.195.195.21.3389: Flags [P.], cksum 0x1ccb (correct), seq 67169:67254, ack 76525, win 1354, options [nop,nop,TS val 745556857 ecr 10155560], length 85
    11:58:20.691749 00:e0:81:c1:48:e0 > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 151: (tos 0x0, ttl 64, id 13711, offset 0, flags [DF], proto TCP (6), length 137)
        192.168.1.11.36768 > 195.195.195.21.3389: Flags [P.], cksum 0x1c9f (correct), seq 67169:67254, ack 76525, win 1354, options [nop,nop,TS val 745556901 ecr 10155560], length 85
    
    

    Gateway-2:

    
    11:58:20.371011 IP (tos 0x0, ttl 64, id 13705, offset 0, flags [DF], proto TCP (6), length 169)
        192.168.1.11.36768 > 195.195.195.21.3389: Flags [P.], cksum 0xed83 (correct), seq 66713:66830, ack 76525, win 1354, options [nop,nop,TS val 745556584 ecr 10155549], length 117
    11:58:20.375781 IP (tos 0x0, ttl 64, id 13706, offset 0, flags [DF], proto TCP (6), length 137)
        192.168.1.11.36768 > 195.195.195.21.3389: Flags [P.], cksum 0xb72c (correct), seq 66830:66915, ack 76525, win 1354, options [nop,nop,TS val 745556588 ecr 10155549], length 85
    11:58:20.388054 IP (tos 0x0, ttl 64, id 13707, offset 0, flags [DF], proto TCP (6), length 137)
        192.168.1.11.36768 > 195.195.195.21.3389: Flags [P.], cksum 0x7b14 (correct), seq 66915:67000, ack 76525, win 1354, options [nop,nop,TS val 745556601 ecr 10155549], length 85
    11:58:20.412274 IP (tos 0x0, ttl 127, id 6467, offset 0, flags [DF], proto TCP (6), length 52)
        195.195.195.21.3389 > 192.168.1.11.36768: Flags [.], cksum 0x422c (correct), ack 66713, win 64000, options [nop,nop,TS val 10155554 ecr 745556541], length 0
    11:58:20.435214 IP (tos 0x0, ttl 127, id 6468, offset 0, flags [DF], proto TCP (6), length 52)
        195.195.195.21.3389 > 192.168.1.11.36768: Flags [.], cksum 0x41ff (correct), ack 66915, win 63798, options [nop,nop,TS val 10155556 ecr 745556584], length 0
    11:58:20.471688 IP (tos 0x0, ttl 127, id 6469, offset 0, flags [DF], proto TCP (6), length 52)
        195.195.195.21.3389 > 192.168.1.11.36768: Flags [.], cksum 0x41ea (correct), ack 67000, win 63713, options [nop,nop,TS val 10155560 ecr 745556601], length 0
    
    11:58:22.367021 IP (tos 0x0, ttl 127, id 6470, offset 0, flags [DF], proto TCP (6), length 153)
        195.195.195.21.3389 > 192.168.1.11.36768: Flags [P.], cksum 0x544d (correct), seq 76525:76626, ack 67000, win 63713, options [nop,nop,TS val 10155749 ecr 745556601], length 101
    
    

    as you can see, pfSense still receives the packets from Machine-A, but didn't forward it. I already turned off "State Killing on Gateway Failure" and also changed all "State Timeouts in Seconds" to 3600 but it doesn't get better. Does someone have similar issues or can help me with my problem?

    Thank you very much in advance!



  • @shadowconnect:

    Here is my setup:

    
                       Gateway-1
                           |
                          WAN
                           |
    Machine-A    pfSense 2.3-RELEASE    Gateway-2
        |                  |                |
        ================= LAN ===============
    
    

    So pfSense has nothing to do with the communication between Machine-A and Gateway-2, since bothe are connected to LAN.

    @shadowconnect:

    There are some IP-addresses, which could only be accessed via Gateway-2. So i added a rule which just set the gateway to Gateway-2 for those IP-addresses.

    If the traffic has to pass pfSense you need a static route for this instead.

    Please explain where the captures are taken from.



  • Thank you very much for your quick answer!

    @viragomann:

    @shadowconnect:

    Here is my setup:

    
                       Gateway-1
                           |
                          WAN
                           |
    Machine-A    pfSense 2.3-RELEASE    Gateway-2
        |                  |                |
        ================= LAN ===============
    
    

    So pfSense has nothing to do with the communication between Machine-A and Gateway-2, since bothe are connected to LAN.

    In theory yes, because Machine-A could directly use Gateway-2, but i don't want to change routing on every machine to Gateway-2. So i just configure pfSense as default gateway on Machine-A and Machine-A don't care about Gateway-1 or Gateway-2 und just send everything to pfSense.

    @viragomann:

    @shadowconnect:

    There are some IP-addresses, which could only be accessed via Gateway-2. So i added a rule which just set the gateway to Gateway-2 for those IP-addresses.

    If the traffic has to pass pfSense you need a static route for this instead.

    I tried that already, but i had problems, when the MTU is different on Gateway-2. When i tried to ping with a length, which is 1 byte over the MTU of Gateway-2, the first paket was send and Machine-A got a response, that it needs to be fragmented. Then Machine-A send out two packets with correct size, but pfSense combined those two packets to one and Gateway-2 received one packet, which is over the needed MTU.

    @viragomann:

    Please explain where the captures are taken from.

    Sorry, my fault, i corrected the log from Gateway, which was Gateway-2.


Log in to reply