We have created Ipsec tunnel using strong-swan as follows,
server (eth interface- 13.13.7.13) --> clinet (eth interface - 13.13.7.18)
when ikev2 phase1 and phae2 messages exchanges happens, source IP and destination IP are same as IP address assigned to eth interfaces. (confirmed via wire-shark). And ISAKMP message exchange has been done successfully.
1) When I started transmitting data via SCP protocol between client & sever , I have noticed ESP and SSH packets.
In which ESP packets just have sequence number but not encrypted payload and SSH packets have encrypted payload. But as per Ipsec protocol data should be encrypted in ESP protocol itself. why there is no payload info in ESP packets ?
FI : I noticed continuous ESP packets after ISAKMP exchange (negotiation and authentication done)
SSH and ESP Packets look like below:
**SSH Protocol**
SSH Version 2 (encryption:chacha20-poly1305#openssh.com mac:<implicit> compression:none)
Packet Length (encrypted): e78d1cd9
Encrypted Packet: 9679398c167c33ca6c1eecc4879e59d417b39545c80b0e40...
MAC: 27b594b6290dcdf3a09fd2fb84884cd7
**ESP Protocol**
Encapsulating Security Payload
ESP SPI: 0xc86cb75d (3362568029)
ESP Sequence: 19
ESP payload ideally not visible in wireshark directly, you need to enable ESP preferences in wireshark tool by providing tunnel SPI, end point IPs, enc/auth keys etc., as mentioned in wiki.
Related
Edit:
I think based on the below answer here, it seems the answer is "client and server basically only communicate on one port, 3478 (or equivalent")
rfc 5766 : Issue when Both devices support TURN
==========================.
I have been reading several sources on TURN, including RFC.
I get the whole premise:
Client creates allocation on TURN server
Client sends data to Peer through TURN that relays via the relayed transport address
Same way around from peer --> Server --> client
Most resources focus on setting up the server and what ports need to be configured.
The point that I am unclear is on the client side:
After the allocation is done and the client can start sending data, do they send that data to the relayed transport address that the Server allocated? Or do they send it to the standard TURN port e.g. 3478, and then the server takes care of looking up the allocation for this client and send it through the relayed address to the peer?
Example:
Client address 192.6.12.123:45677 (let's assume it's the NAT)
TURN server listens on 34.45.34.123:3478
TURN server has done an allocation for client on 34.45.34.123:50678
So when the client wants to send to a peer application data, do they send on port 3478 or port 50678?
My assumption (based also on some wireshark captures I tried) is that the client always send everything on port 3478 and the server takes care to send via the relayed address.
My assumption (based also on some wireshark captures I tried) is that the client always send everything on port 3478
The client will pick a random local port (e.g 45677), but traffic sent from this port goes to the server's port 3478 (or 5349 if using TLS) on the server. The server will forward it through its allocated port (50678) to whatever remote port the other client established during ICE negotiation.
We have a TURN fleet that has presence with the AWS Regions US-EAST-1 and US-WEST-2.
A client in the Ukraine is trying to connect to a peer in the United Kingdom. Both the client and the peer are behind a symmetric NAT.
The client does not have access to TURN credentials.
The peer does have access to TURN credentials.
The result is:
client:
host
server reflexive
peer:
host
server reflexive
relay
Our TURN fleet creates permissions in IP addresses ONLY, and ignores the port variations.
Success case: Client initiates a call through US-EAST-1.
Client gathers its host, and server reflexive candidate. Sends them to peer.
Peer receives the clients candidates, and gathers its own host, server reflexive and relay candidate. Sends them to the client.
The client sends a STUN binding to the relay transport address.
The TURN relay sees the request, attaches an XOR-PEER-ADDRESS to it and forwards it to the client via a DATA indication.
The client sees the request, generates a response, and sends it to the relay via a SEND indication.
The relay accepts and forwards the message to the peer.
The peer unwraps the XOR-PEER-ADDRESS, determining it to be a peer reflexive candidate and sets the active pair as local: prflx | remote: relay.
Media flows, everyone is happy.
Failure case: Client initiates a call through US-WEST-2.
Steps 1 to 6 occur as they did above.
The peer never receives the response from the TURN server containing the peer reflexive candidate in the XOR-PEER-ADDRESS.
Since it is a symmetric NAT, the call fails.
This only happens to a particular peer, as we see thousands of prflx / relay calls happening in US-WEST-2 even at this very moment. I don't have any reason to believe that the TURN server failed to send the response.
Security groups for outgoing are fully permissive (for IPv4/6) and are identical.
0.0.0.0/0
::/0
The config files in both regions are identical. As far as my exhaustive search has taken me, the only difference between the two calls is the AWS Region that the calls are made through. I could be mistaken, but I've combed through every little detail I could think of.
I've even tested US-EAST-1 and US-WEST-2 myself through a symmetric NAT and was able to establish a prflx-relay call.
Has anyone encountered this before?
Binding Request (peer -> TURN)
1094 5.262769 192.168.1.202 TURN_IP_ADDRESS STUN
170 Binding Request user: 0kZJvRw4xieMyZWtgrfSvGh6EzfhRzxP:5Vi8
TURN to Client DATA indication:
3942 8.729590 TURN_IP_ADDRESS 192.168.1.202 STUN
150 Binding Success Response XOR-MAPPED-ADDRESS: 1.2.3.4:9976 user: ttsEVBZnkpBftWENErHh+3HkiEj3xoU2:8/DZ
Client Receives message:
3272 7.757723 TURN_IP_ADDRESS 192.168.88.108 STUN
250 Data Indication XOR-PEER-ADDRESS: 1.2.3.4:9976
Client Creates a permission:
CreatePermission Request XOR-PEER-ADDRESS: 1.2.3.4:9976 with nonce realm: amazonaws.com user: { USERNAME }
Client responds:
3358 7.930904 192.168.88.108 TURN_IP_ADDRESS STUN
186 Send Indication XOR-PEER-ADDRESS: 1.2.3.4:9976
TURN to Peer response:
nothing received by the peer
Client continues to receive DATA indications of:
3272 7.757723 TURN_IP_ADDRESS 192.168.88.108 STUN
250 Data Indication XOR-PEER-ADDRESS: 1.2.3.4:9976
and continues to respond with:
3358 7.930904 192.168.88.108 TURN_IP_ADDRESS STUN
186 Send Indication XOR-PEER-ADDRESS: 1.2.3.4: 9976
Eventually the call times out.
I'm in a hurry at the moment.
My Question is, is there a way to forward UDP to TCP port?
I need this for hosting a game server for my friends, I want to
host Counter-Strike server for example, but it uses UDP (User Datagram Protocol) for server port, but NGROK only supports TCP (Transmission Control Protocl) & HTTP (HyperText Transfer Protocol).
I tried this while ago..
ngrok tcp 127.0.0.1:27015
and as usually it will start :
ngrok by #inconshreveable (Ctrl+C to quit)
Session Status online
Account Soricy Infinitive (Plan: Free)
Version 2.2.8
Region United States (us)
Web Interface http://127.0.0.1:4040
Forwarding tcp://0.tcp.ngrok.io:18833 -> 127.0.0.1:27015
Connections ttl opn rt1 rt5 p50 p90
0 0 0.00 0.00 0.00 0.00
But fails to connect to 0.tcp.ngrok.io:18833 in the game, and displays that there is no UDP configured on the server side.
Is there any way I could do this differently? UDP=>TCP?
Checkout DatagramTunnneler (on github). It is an open-source c++ program which simply listens to UDP traffic and forwards it to a TCP endpoint of your choice. On that TCP endpoint another instance of the DatagramTunneler publishes the UDP data back onto a UDP channel.
Disclaimer: I wrote that tool.
One way is to copy the "raw" udp Payload and create a new TCP packet with the raw payload. But you need to set the same data of the other layer except the udp layer. Also: You need a clean configuration of the tcp layer.
I am working on a project consisting of the bidirectionnal (and secure) connexion of a lot of Raspberry PI -N clients- to a known, accessible, fixed-IP adress Server.
The clients (Raspberry PI) are all connected to the Internet via a classic NAT. Let say clients are identified by a number between 1 and N.
[Client] Raspberry PI <-> NAT (Internet Provider) <-> Internet
All client's public IP are dynamic
The Server is located somewhere on the Internet at the IP address A
--- My GOAL : Connect each client to the server with the SSH protocol. ---
The Server needs to send data at will to any client (no broadcast), and each client needs to send data to the server.
There will be "N" SSH tunnels, initiated by the clients , using reverse-port forwarding or/and port forwarding.
That's where i lack knowledge in SSH:
1) How can the server associate each tunnels with a client in
order to be able to use the proper tunnel ? How can a program (for
example in C) identify and "use" each tunnel for sending and receving
server-side?
2) Using [reverse] port forwarding, what are the needs in ports
server side, does each clients needs a remote port on the server?
3) Do i need to create a program that link each outgoing port to a
client ID and same thing for ingoing port?
My problem is when the server needs to send data to a specific client, how to do it ?
Thank you very much.
I'm tunneling all of my internet traffic through a remote computer hosting Debian using sshd. But my internet connection becomes so slow (something around 5 to 10 kbps!). Can be anything wrong with the default configuration to cause this problem?
Thanks in advance,
Tunneling TCP within another TCP stream can sometimes work -- but when things go wrong, they go wrong very quickly.
Consider what happens when the "real world" loses one of your TCP packets: after a certain amount of not getting an ACK packet back in response to new data packets, the sending side realizes a packet has gone missing and re-sends the data.
If that packet happens to be a TCP packet whose payload is another TCP packet, then you have two TCP stacks that are upset about their missing packet. The tunneled TCP layer will re-send packets and the outer TCP layer will also resend packets. This causes a giant pileup of duplicate packets that will eventually be delivered and must be dropped on the floor -- because the outer TCP reliably delivered the packet, eventually.
I believe you would be much better served by a more dedicated tunneling method such as GRE tunnels or IPSec.
Yes, tunelling traffic over tcp connection is not a good idea. See http://sites.inka.de/bigred/devel/tcp-tcp.html