github-starred/frp

Fork 0

mirror of https://github.com/fatedier/frp.git synced 2026-05-15 08:05:49 -06:00

[GH-ISSUE #3717] nathole need a ip filter for zerotiler-like virtual network[Feature Request] #2959

New issue

Closed

opened 2026-05-05 13:54:37 -06:00 by gitea-mirror · 9 comments

gitea-mirror commented

2026-05-05 13:54:37 -06:00

Owner

Originally created by @yangyaofei on GitHub (Oct 23, 2023).
Original GitHub issue: https://github.com/fatedier/frp/issues/3717

Describe the feature request

Like this issue: https://github.com/fatedier/frp/issues/3457, the zerotier ip has a low TTL.
So , the nathole will use zerotier for transmission. But the zerotier can be very slow.

I think add a config nat_address_filter like 192.168.0.0/24 which will remove these ips from nathole.

To test that thought, I add several code in https://github.com/fatedier/frp/blob/dev/client/visitor/xtcp.go#L278:


func (sv *XTCPVisitor) makeNatHole() {
	xl := xlog.FromContextSafe(sv.ctx)
	xl.Trace("makeNatHole start")
	if err := nathole.PreCheck(sv.ctx, sv.helper.MsgTransporter(), sv.cfg.ServerName, 5*time.Second); err != nil {
		xl.Warn("nathole precheck error: %v", err)
		return
	}

	xl.Trace("nathole prepare start")
	prepareResult, err := nathole.Prepare([]string{sv.clientCfg.NatHoleSTUNServer})
	if err != nil {
		xl.Warn("nathole prepare error: %v", err)
		return
	}
        // Simple Filter one IP
	var ipAddress = "172.16.1.70"
	var filteredAddrs []string
	for _, addr := range prepareResult.AssistedAddrs {
		addrParts := strings.Split(addr, ":")
		if addrParts[0] != ipAddress {
			filteredAddrs = append(filteredAddrs, addr)
		}
	}
	prepareResult.AssistedAddrs = filteredAddrs

I test the code above, it will make frp go direct not through zerotier.

Describe alternatives you've considered

The things I don't know is that if this is a good implement or not. Totally newbie for go.

So if this is good and this config make sense, I will make a PR for this.

Affected area

Docs
Installation
Performance and Scalability
Security
User Experience
Test and Release
Developer Infrastructure
Client Plugin
Server Plugin
Extensions
Others

Originally created by @yangyaofei on GitHub (Oct 23, 2023). Original GitHub issue: https://github.com/fatedier/frp/issues/3717 ### Describe the feature request Like this issue: https://github.com/fatedier/frp/issues/3457, the zerotier ip has a low TTL. So , the nathole will use zerotier for transmission. But the zerotier can be very slow. I think add a config `nat_address_filter` like `192.168.0.0/24` which will remove these ips from nathole. To test that thought, I add several code in https://github.com/fatedier/frp/blob/dev/client/visitor/xtcp.go#L278: ```go func (sv *XTCPVisitor) makeNatHole() { xl := xlog.FromContextSafe(sv.ctx) xl.Trace("makeNatHole start") if err := nathole.PreCheck(sv.ctx, sv.helper.MsgTransporter(), sv.cfg.ServerName, 5*time.Second); err != nil { xl.Warn("nathole precheck error: %v", err) return } xl.Trace("nathole prepare start") prepareResult, err := nathole.Prepare([]string{sv.clientCfg.NatHoleSTUNServer}) if err != nil { xl.Warn("nathole prepare error: %v", err) return } // Simple Filter one IP var ipAddress = "172.16.1.70" var filteredAddrs []string for _, addr := range prepareResult.AssistedAddrs { addrParts := strings.Split(addr, ":") if addrParts[0] != ipAddress { filteredAddrs = append(filteredAddrs, addr) } } prepareResult.AssistedAddrs = filteredAddrs ``` I test the code above, it will make frp go direct not through zerotier. ### Describe alternatives you've considered **The things I don't know is that if this is a good implement or not. Totally newbie for go.** So if this is good and this config make sense, I will make a PR for this. ### Affected area - [ ] Docs - [ ] Installation - [X] Performance and Scalability - [ ] Security - [ ] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [ ] Server Plugin - [ ] Extensions - [ ] Others

gitea-mirror

2026-05-05 13:54:37 -06:00

closed this issue
added the
proposal
label

gitea-mirror commented

2026-05-05 13:54:39 -06:00

Author

Owner

@fatedier commented on GitHub (Oct 23, 2023):

I don't understand why you would want to use both zerotier and frp at the same time. Zerotier already supports peer-to-peer (p2p) connections, so I don't see the need to introduce more configuration complexity by using frp.

@fatedier commented on GitHub (Oct 23, 2023): I don't understand why you would want to use both zerotier and frp at the same time. Zerotier already supports peer-to-peer (p2p) connections, so I don't see the need to introduce more configuration complexity by using frp.

gitea-mirror commented

2026-05-05 13:54:40 -06:00

Author

Owner

@yangyaofei commented on GitHub (Oct 23, 2023):

@fatedier zerotier rubost and easy to use for a group of people to connect each others. I use it for ssh.

but it is not stable, and slow due to the reason that we all know. And it cannot make nat hole in my network(but frp can). So,when we need to debug or transfer files or deploy service from Lan to web site, we will use frp.

I need them all😂😂😂

@yangyaofei commented on GitHub (Oct 23, 2023): @fatedier zerotier rubost and easy to use for a group of people to connect each others. I use it for ssh. but it is not stable, and slow due to the reason that we all know. And it cannot make nat hole in my network(but frp can). So,when we need to debug or transfer files or deploy service from Lan to web site, we will use frp. I need them all😂😂😂

gitea-mirror commented

2026-05-05 13:54:41 -06:00

Author

Owner

@fatedier commented on GitHub (Oct 23, 2023):

I tend to put it aside first and wait for more feedback on this scenario.

@fatedier commented on GitHub (Oct 23, 2023): I tend to put it aside first and wait for more feedback on this scenario.

gitea-mirror commented

2026-05-05 13:54:42 -06:00

Author

Owner

@yangyaofei commented on GitHub (Oct 23, 2023):

Can I make PR for this?

@yangyaofei commented on GitHub (Oct 23, 2023): Can I make PR for this?

gitea-mirror commented

2026-05-05 13:54:43 -06:00

Author

Owner

@fatedier commented on GitHub (Oct 23, 2023):

It will not accepted until we have clear and meaningful problem scenarios that are helpful to most people, especially when new configuration items need to be added.

The scenario you described, from my personal perspective, does not seem worth adding new configuration options to solve the problem. However, I am unsure if this is a common requirement for disabling internal addresses in AssistedAddrs(something like DisableInnerAssistedAddrs) , so I will temporarily leave it here and wait for more feedback from users.

@fatedier commented on GitHub (Oct 23, 2023): It will not accepted until we have clear and meaningful problem scenarios that are helpful to most people, especially when new configuration items need to be added. The scenario you described, from my personal perspective, does not seem worth adding new configuration options to solve the problem. However, I am unsure if this is a common requirement for disabling internal addresses in AssistedAddrs(something like `DisableInnerAssistedAddrs`) , so I will temporarily leave it here and wait for more feedback from users.

gitea-mirror commented

2026-05-05 13:54:43 -06:00

Author

Owner

@yangyaofei commented on GitHub (Oct 23, 2023):

ok, I think most users can't notice this. This (wrong nathole) will disappear in lots of circumstances. I think it more like a performance bug (but it's a feature).

I will fork this for my own usage, pin me if you need a PR.

@yangyaofei commented on GitHub (Oct 23, 2023): ok, I think most users can't notice this. This (wrong nathole) will disappear in lots of circumstances. I think it more like a performance bug (but it's a feature). I will fork this for my own usage, pin me if you need a PR.

gitea-mirror commented

2026-05-05 13:54:44 -06:00

Author

Owner

@fatedier commented on GitHub (Oct 23, 2023):

@yangyaofei BTW, I think you can consider whether there is a possibility of optimization without introducing new configuration items.

I prefer not to expose complexity to users as it may increase their understanding cost. Many users may also misuse it, resulting in various issues being created, which will ultimately lead to high maintenance costs for the project. Not just this one feature, I mean various kinds of requirements. Some features may only be used by a few people in the end, but in order to ensure the correctness of each refactoring/iteration, it is necessary for developers to invest in long-term maintenance costs.

@fatedier commented on GitHub (Oct 23, 2023): @yangyaofei BTW, I think you can consider whether there is a possibility of optimization without introducing new configuration items. I prefer not to expose complexity to users as it may increase their understanding cost. Many users may also misuse it, resulting in various issues being created, which will ultimately lead to high maintenance costs for the project. Not just this one feature, I mean various kinds of requirements. Some features may only be used by a few people in the end, but in order to ensure the correctness of each refactoring/iteration, it is necessary for developers to invest in long-term maintenance costs.

gitea-mirror commented

2026-05-05 13:54:45 -06:00

Author

Owner

@yangyaofei commented on GitHub (Oct 23, 2023):

I understand this philosophy but not fully agree. I think smart optimization may lead some unknown issues and hard to find and resolve.

Maybe add a config like enableSmartNatHole to enable is a good way.

@yangyaofei commented on GitHub (Oct 23, 2023): I understand this philosophy but not fully agree. I think **smart** optimization may lead some unknown issues and hard to find and resolve. Maybe add a config like `enableSmartNatHole` to enable is a good way.

gitea-mirror commented

2026-05-05 13:54:45 -06:00

Author

Owner

@aa51513 commented on GitHub (Dec 4, 2024):

I think specifying a network card for xtcp is very necessary.
mainly reflected in two aspects:
① Avoid attempts to make hole for unnecessary network cards(such as docker tun or point-to-point direct link);
② Avoid interfering with other software or tools(such as zerotier,to some extent, it overlaps with the first one);

In addition, I understand how to use the transport.connectServerLocalIP parameter , but it doesn't help me
to achieve the purpose, because in most scenarios, the IP of the network card is obtained through DHCP and is not a fixed value.

@aa51513 commented on GitHub (Dec 4, 2024): I think specifying a network card for xtcp is very necessary. mainly reflected in two aspects: ① Avoid attempts to make hole for unnecessary network cards(such as docker tun or point-to-point direct link); ② Avoid interfering with other software or tools(such as zerotier,to some extent, it overlaps with the first one); In addition, I understand how to use the `transport.connectServerLocalIP` parameter , but it doesn't help me to achieve the purpose, because in most scenarios, the IP of the network card is obtained through DHCP and is not a fixed value.