Closed mfoxworthy closed 1 year ago
parvit
commented
2 years ago Just to check: are you running the client with admin privileges?
Also use an ip of a real network interface for the listening address, mixing real interfaces with loopback does not work for windivert.
mfoxworthy
commented
2 years ago Just to check: are you running the client with admin privileges?
Also use an ip of a real network interface for the listening address, mixing real interfaces with loopback does not work for windivert.
I am running it as admin. So, I just need to use the IP the DHCP server gave my VM? I think we should try to autodetect that with the default route interface. That might also be the issue we are seeing with the tray-icon too.
parvit
commented
2 years ago So, I just need to use the IP the DHCP server gave my VM? In general you need an ip on a real interface, because windivert cannot redirect correctly when using the loopback interface.
I'll track the improvement with this ticket and i can work on it when the other priorities are done.
mfoxworthy
commented
2 years ago So, I just need to use the IP the DHCP server gave my VM? In general you need an ip on a real interface, because windivert cannot redirect correctly when using the loopback interface.
I'll track the improvement with this ticket and i can work on it when the other priorities are done.
Hi Vittorio, I tried to add the client IP and I am still unable to connect. Here is the log after I made the change.
PS C:\Users\mfoxworthy\Downloads\qpep-main> ./qpep.exe -client -gateway 52.40.157.87 -port 1443 -listenaddress 10.0.4.13 2 2022/08/05 09:29:43 Server statistics reset. 09:29:43.849551 ARGS: C:\Users\mfoxworthy\Downloads\qpep-main\qpep.exe -client -gateway 52.40.157.87 -port 1443 -listenaddress 10.0.4.132 09:29:43.850551 { "AckElicitingPacketsBeforeAck": 10, "AckDecimationDenominator": 4, "InitialCongestionWindowPackets": 4, "MultiStream": true, "VarAckDelay": 0.25, "MaxAckDelay": 25, "MinReceivedBeforeAckDecimation": 100, "ClientFlag": true, "GatewayIP": "52.40.157.87", "GatewayPort": 1443, "GatewayAPIPort": 444, "ListenIP": "10.0.4.132", "ListenPort": 9443, "WinDivertThreads": 1, "Verbose": false } 09:29:43.851554 Running Client 09:29:43.852470 Diverter messages will be ignored 09:29:43.874578 Starting TCP-QPEP Tunnel Listener 09:29:43.876570 Client configuration validation OK 09:29:43.876570 Binding to TCP 10.0.4.132:9443 09:29:44.881598 local: 10.0.4.132 - 10.0.4.132 09:29:44.883699 Accepting TCP connection from 10.0.4.132:60546 with destination of 10.0.4.132:9443 09:29:44.883699 Dialing QUIC Session: 52.40.157.87:1443 09:29:45.027738 Accepting TCP connection from 10.0.4.132:60549 with destination of 10.0.4.132:9443 09:29:45.027738 Dialing QUIC Session: 52.40.157.87:1443 09:29:45.382774 ERROR: Get "http://52.40.157.87:444/api/v1/echo": context deadline exceeded (Client.Timeout exceeded while awaiting headers) 09:29:45.384763 Gateway Echo FAILED 09:29:46.386925 local: 10.0.4.132 - 10.0.4.132 09:29:46.395953 Accepting TCP connection from 10.0.4.132:60550 with destination of 10.0.4.132:9443 09:29:46.400852 Dialing QUIC Session: 52.40.157.87:1443 09:29:46.888926 ERROR: Get "http://52.40.157.87:444/api/v1/echo": context deadline exceeded (Client.Timeout exceeded while awaiting headers) 09:29:46.890973 Gateway Echo FAILED 09:29:47.319004 Accepting TCP connection from 10.0.4.132:58458 with destination of 10.0.4.132:9443 09:29:47.321041 Dialing QUIC Session: 52.40.157.87:1443 09:29:47.604999 Accepting TCP connection from 10.0.4.132:62850 with destination of 10.0.4.132:9443 09:29:47.607063 Dialing QUIC Session: 52.40.157.87:1443 09:29:47.607063 Accepting TCP connection from 10.0.4.132:50092 with destination of 10.0.4.132:9443 09:29:47.612079 Dialing QUIC Session: 52.40.157.87:1443
bizzbyster
commented
2 years ago 09:29:43.852470 Diverter messages will be ignored
Does the above message concern you?
parvit
commented
2 years ago @bizzbyster That simply means that the log messages coming from the diverter are ignored, because they are a performance penalty but if you want to see them then you can specify the "-verbose" flag.
@mfoxworthy The redirection host -> client seems to be working as expected
09:29:44.883699 Accepting TCP connection from 10.0.4.132:60546 with destination of 10.0.4.132:9443
09:29:44.883699 Dialing QUIC Session: 52.40.157.87:1443But then there seems to be no connection to the api server:
09:29:46.888926 ERROR: Get "http://52.40.157.87:444/api/v1/echo": context deadline exceeded (Client.Timeout exceeded while awaiting headers)We should check if the api ports specified on the client and server match, could you post the log from the server too?
mfoxworthy
commented
2 years ago @bizzbyster That simply means that the log messages coming from the diverter are ignored, because they are a performance penalty but if you want to see them then you can specify the "-verbose" flag.
@mfoxworthy The redirection host -> client seems to be working as expected
09:29:44.883699 Accepting TCP connection from 10.0.4.132:60546 with destination of 10.0.4.132:9443 09:29:44.883699 Dialing QUIC Session: 52.40.157.87:1443But then there seems to be no connection to the api server:
09:29:46.888926 ERROR: Get "http://52.40.157.87:444/api/v1/echo": context deadline exceeded (Client.Timeout exceeded while awaiting headers)We should check if the api ports specified on the client and server match, could you post the log from the server too?
I see what is happening. So first it appears that when I finally made the tray config changes for the local IP of the client, windows wanted me to do something with the firewall that I didn't see at first. So I fixed that. Now I see diverted sessions and they are working.
Now I am seeing why the tray apiport part isn't working. The AWS EC2 instance is actually behind a NAT. All packets going to 52.40.157.87 actually go to 172.31.38.198. So, when the TCP connection to the api comes out of the QUIC tunnel, it is trying to connect to 52.40.157.87:443. That would be a hairpin route that I don't have control over. We either need to detect that on the server so that when the connection is made it is made to the listeningaddress or we need a new config on the client for apiaddress.
parvit
commented
2 years ago Try setting the listening address as the real IP if possible.
Also please load the server log file i might be able to better help you.
Il Ven 5 Ago 2022, 19:31 Michael Foxworthy @.***> ha scritto:
@bizzbyster https://github.com/bizzbyster That simply means that the log messages coming from the diverter are ignored, because they are a performance penalty but if you want to see them then you can specify the "-verbose" flag.
@mfoxworthy https://github.com/mfoxworthy The redirection host -> client seems to be working as expected
09:29:44.883699 Accepting TCP connection from 10.0.4.132:60546 with destination of 10.0.4.132:9443 09:29:44.883699 Dialing QUIC Session: 52.40.157.87:1443
But then there seems to be no connection to the api server:
09:29:46.888926 ERROR: Get "http://52.40.157.87:444/api/v1/echo": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
We should check if the api ports specified on the client and server match, could you post the log from the server too?
I see what is happening. So first it appears that when I finally made the tray config changes for the local IP of the client, windows wanted me to do something with the firewall that I didn't see at first. So I fixed that. Now I see diverted sessions and they are working.
Now I am seeing why the tray apiport part isn't working. The AWS EC2 instance is actually behind a NAT. All packets going to 52.40.157.87 actually go to 172.31.38.198. So, when the TCP connection to the api comes out of the QUIC tunnel, it is trying to connect to 52.40.157.87:443. That would be a hairpin route that I don't have control over. We either need to detect that on the server so that when the connection is made it is made to the listeningaddress or we need a new config on the client for apiaddress. [image: Screen Shot 2022-08-05 at 10 19 38 AM] https://user-images.githubusercontent.com/8184748/183130227-4737c689-0807-4671-9b2e-b8a04445e9f3.png
— Reply to this email directly, view it on GitHub https://github.com/Project-Faster/qpep/issues/11#issuecomment-1206685743, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWGJD4BJT56MNR7RMXUL2I3VXVFW5ANCNFSM55QH2RRA . You are receiving this because you were assigned.Message ID: @.***>
parvit
commented
2 years ago You also might want to try first with a simpler setup.
Il Ven 5 Ago 2022, 20:17 Vittorio Parrella @.***> ha scritto:
Try setting the listening address as the real IP if possible.
Also please load the server log file i might be able to better help you.
Il Ven 5 Ago 2022, 19:31 Michael Foxworthy @.***> ha scritto:
@bizzbyster https://github.com/bizzbyster That simply means that the log messages coming from the diverter are ignored, because they are a performance penalty but if you want to see them then you can specify the "-verbose" flag.
@mfoxworthy https://github.com/mfoxworthy The redirection host -> client seems to be working as expected
09:29:44.883699 Accepting TCP connection from 10.0.4.132:60546 with destination of 10.0.4.132:9443 09:29:44.883699 Dialing QUIC Session: 52.40.157.87:1443
But then there seems to be no connection to the api server:
09:29:46.888926 ERROR: Get "http://52.40.157.87:444/api/v1/echo": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
We should check if the api ports specified on the client and server match, could you post the log from the server too?
I see what is happening. So first it appears that when I finally made the tray config changes for the local IP of the client, windows wanted me to do something with the firewall that I didn't see at first. So I fixed that. Now I see diverted sessions and they are working.
Now I am seeing why the tray apiport part isn't working. The AWS EC2 instance is actually behind a NAT. All packets going to 52.40.157.87 actually go to 172.31.38.198. So, when the TCP connection to the api comes out of the QUIC tunnel, it is trying to connect to 52.40.157.87:443. That would be a hairpin route that I don't have control over. We either need to detect that on the server so that when the connection is made it is made to the listeningaddress or we need a new config on the client for apiaddress. [image: Screen Shot 2022-08-05 at 10 19 38 AM] https://user-images.githubusercontent.com/8184748/183130227-4737c689-0807-4671-9b2e-b8a04445e9f3.png
— Reply to this email directly, view it on GitHub https://github.com/Project-Faster/qpep/issues/11#issuecomment-1206685743, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWGJD4BJT56MNR7RMXUL2I3VXVFW5ANCNFSM55QH2RRA . You are receiving this because you were assigned.Message ID: @.***>
mfoxworthy
commented
2 years ago You also might want to try first with a simpler setup. Il Ven 5 Ago 2022, 20:17 Vittorio Parrella @.> ha scritto: … Try setting the listening address as the real IP if possible. Also please load the server log file i might be able to better help you. Il Ven 5 Ago 2022, 19:31 Michael Foxworthy @.> ha scritto: > @bizzbyster https://github.com/bizzbyster That simply means that the log > messages coming from the diverter are ignored, because they are a > performance penalty but if you want to see them then you can specify the > "-verbose" flag. > > @mfoxworthy https://github.com/mfoxworthy The redirection host -> > client seems to be working as expected > > 09:29:44.883699 Accepting TCP connection from 10.0.4.132:60546 with destination of 10.0.4.132:9443 > 09:29:44.883699 Dialing QUIC Session: 52.40.157.87:1443 > > But then there seems to be no connection to the api server: > > 09:29:46.888926 ERROR: Get "http://52.40.157.87:444/api/v1/echo": context deadline exceeded (Client.Timeout exceeded while awaiting headers) > > We should check if the api ports specified on the client and server > match, could you post the log from the server too? > > I see what is happening. So first it appears that when I finally made the > tray config changes for the local IP of the client, windows wanted me to do > something with the firewall that I didn't see at first. So I fixed that. > Now I see diverted sessions and they are working. > > Now I am seeing why the tray apiport part isn't working. The AWS EC2 > instance is actually behind a NAT. All packets going to 52.40.157.87 > actually go to 172.31.38.198. So, when the TCP connection to the api comes > out of the QUIC tunnel, it is trying to connect to 52.40.157.87:443. > That would be a hairpin route that I don't have control over. We either > need to detect that on the server so that when the connection is made it is > made to the listeningaddress or we need a new config on the client for > apiaddress. > [image: Screen Shot 2022-08-05 at 10 19 38 AM] > https://user-images.githubusercontent.com/8184748/183130227-4737c689-0807-4671-9b2e-b8a04445e9f3.png > > — > Reply to this email directly, view it on GitHub > <#11 (comment)>, > or unsubscribe > https://github.com/notifications/unsubscribe-auth/AWGJD4BJT56MNR7RMXUL2I3VXVFW5ANCNFSM55QH2RRA > . > You are receiving this because you were assigned.Message ID: > @.***> >
I was actually able to make it work using a OUTPUT NAT rule with iptables.
sudo iptables -t nat -A OUTPUT -p tcp -d 52.40.157.87 --dport 444 -j DNAT --to-destination 172.31.38.198:444
However, I am using the real IP on the listener. If I try to use the public it fails. My command is:
sudo ./qpep -listenaddress 172.31.38.198 -listenport 1443
So now things are working but I have a few issues I am going to document. Autodecting the IP of the client is critical so let's leave this issue here with the label we alreadt have and start tracking that on here. I will open a discussion and a table to start tracking these. Sound good?
parvit
commented
2 years ago you will find the table under the organization already with all the tickets up to now.
EDIT: https://github.com/orgs/Project-Faster/projects/2/views/1
parvit
commented
2 years ago Another requirement is for the server to rewrite the API requests for the listening address not the gateway address.
EDIT: tracked in issue #16
parvit
commented
2 years ago @mfoxworthy @bizzbyster The PR for this change is ready for testing
mfoxworthy
commented
2 years ago I had to configure the listenaddress for it to work. Is there something else I have to do to make it autodetect?
parvit
commented
2 years ago Hi, yes i did specify in the PR that the autodetection kicks in only if the address being specified starts with "127." or "0." (this change also set the defaults accordingly)
- Support for autodetecting the listening address for both client and server, if the provided address begins with "0." or "127." which are not suitable addresses
So in short, if one does not specify an explicit "-listenaddress" than it will try to autodetect, but one can still be specified to use in the cli or the tray configuration file
parvit
commented
1 year ago Feature tested positively and merged.
Here is a client log running the client from the command line on a Windows VM.