I want to know whether vyos supports CGNat. If not, is there any possibility in future
There’s discussion about it here.
Try the config described here
let me check. I will update after testing
I have setup pn laptop and almost 1Gig traffic is passing through it. Till npw its working fine. I will test this for almost a week. In order to resolve all the issues before shifting into prosuction
How does it work in production?
Could you describe in detail how many internal/external addresses you use?
Do you have any issues?
I tested for about 1 week. /22 private ip pool and 2 / 29 external pools. 1001-65535 port. With 1000 port per user. Work perfectly. Got no complaint. Today, I made a test environment again. Almost 400 subscribers are connected. Note, number of subscribers were same in previous test.
One thing I noticed today. If remove a public ip pool its enyries are not flushed from nat translation table
@Saad How to reproduce?
Did you use two external addresses for the pool and then delete one of them? Something else?
Can you add steps to reproduce and open a bug report?
Thanks
By the way we have documentation about this feature CGNAT — VyOS 1.5.x (circinus) documentation
I added another /29 external pool and removed a previous. Means, I replaced a previous external pool with another one.
Excellent. I will check this
What NAT type are your users reporting on real-time applications such as gaming? While yes, the implementation here “functions”, online matchmaking capabilities are reduced for users due to NAT type being too strict. This is a direct result of not having endpoint independent filtering support in the VyOS NAT implementation.
I encourage you to check your NAT types and follow closely to user reports of limited matchmaking opportunities, higher gaming latency due to having to expand the match making search radius, and voice chat capabilities.
Do you have any idea how to implement it via nftables?
What will be if 2-4 subscribers behind one external address needs to use the same ports, port-ranges?
Are there easy way to check peer-to-peer communication without Xbox?
Rfc 6887 and 6888 still requires developing process, not all requirements are implemented
The root task for CGN âš“ T5169 Add CGNAT Carrier-Grade NAT based on nftables
You can add more subtasks or claim any sub task if you want.
EIF does not have anything to do with re-using the same ports or ranges. It can operate on any external port translated by the underlying NAT technique (not dependent on the technique). In an Xbox scenario what happens is that one Xbox host (“server”) calls out to an external server (Xbox Live) which opens a public IP:port translation. Then the Xbox Live network communicates to the other Xbox hosts (clients) to connect to the public IP:port of the server host’s opened connection described previously. In an EIF implementation the connection is allowed and communication to the server public IP:port is treated as transparent in regards to limiting the IPs and ports that can connect to it. Without EIF, the connection to the server’s public IP:port would be blocked and restricted to only work between the Xbox server host and Xbox Live network thus preventing any clients from being able to connect to it.
You can check EIF easily by running tcpdump and opening an outbound connection on a Linux host configured to be behind CGN to some host on the Internet, notate the public IP:port translated by the CGN, and try to initiate an inbound connection from a different Linux host on the Internet to the public:IP port. If tcpdump captures the inbound packets on the Linux host then the CGN is working transparently and passing packets with EIF. If it doesn’t then there’s some other issue or EIF is not working.
Subtask is already here: âš“ T6247 Add CGN "full cone" EIF support per RFC6888 REQ-7
Unfortunately this would require modification of the base nftables and recompile in C which I do not know. I’m a network development engineer, not a SDE My capabilities stop at Python but I can definitely test and explain how the feature should work functionally. These patch files seem to have been made to implement to OpenWRT though:
If someone could just get this over the line into Debian/Gnu for VyOS we would be golden!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.