How to open / redirect port for desired source only?

[Alen]

1. I need to make a hole in the firewall for traffic from particular Internet source ip : port only and redirect it to particular LAN PC. Is it possible?
I mean allow traffic from x.y.z.t : xxx destined to Wingate ip and then redirect it to particular LAN PC.


2. And the same question for any traffic from predifined ip, without port restrictions: allow any traffic from x.y.z.t destined to Wingate ip and then redirect it to particular LAN PC.

Is these possible?

[Nev]

To 2) do you mean source routing? EG: public ip xxx.xx.xxx.x *only* can connect without restriction to the Wingate machine and then redirect, I believe not in Wingate 6.x.

To 1) yes in the ENS Port Security like this is probably what you need:

Attachments

Inbound Port Redirection In Wingate 6.x

Port.redirect.gif (21.98 KiB) Viewed 7084 times

[Alen]

To 2) do you mean source routing? EG: public ip xxx.xx.xxx.x *only* can connect without restriction to the Wingate machine and then redirect, I believe not in Wingate 6.x.

Yes. I need the whole traffic from the public ip xxx.xx.xxx.x to be passed through Wingate and be redirected to a particular PC in LAN.
And I am using Wingate 6.

P.S. I supposed this is not possible, but just wanted to be sure.
What about Wingate 7?

To 1) yes in the ENS Port Security like this is probably what you need:

Yes, I made the same (still can't check the result, because need to think what to do on the border Cisco. Wingate is not on the perimeter edge, Cisco router is. This creates quite a big problem for me in light of this task...).

But I don't understand two options you checked: override port and "Don't translate source IP".

The first option, I suppose, is used because you set the remote host(s) to use TCP 5077 or 5078 for RDP and the same time you don't want to change the default port values on the LAN PC (I believe the server - host which have to be remotely controlled). Is this correct?

But what is the second one for? I can't see anything about it in the help.

[Alen]

Report:
I solved my task. And did it the right way, not the one I choosed initially.

The full task was the following: allow tunelled GRE + PPTP traffic (more precisely replies on my clients requests) from one public ip to some of my users. So port redirection was not the right solution, as in that case I would need something like "destination-based" port forwarding, when data received by Wingate on port "n" is redirected to the client for whom NAT\Proxy used that port "n" as source port when it sends packet to the public ip.
BTW: can Wingate 7 do such things? (I believe Wingate 6 cann't.)


Now, the right decision was possible because I have a border Cisco installed after Wingate. And I just allowed GRE traffic on my border Cisco from that very ip only plus on Wingate I made a hole (not port redirection) for PPTP (TCP 1723). As a result I get: TCP 1723 from one public ip only to enter my network. And it works just wonderful.


But, anyway, it will be nice, if in Wingate we can make holes and port redirections not only for a specified port, but also specified ip:port or even range of ips:range of ports!

In that case it will be possible to:
1. permit traffic from specified ips:ports only or just specified public ips (meaning, all traffic from that ips - by setting range of ports = 0-65535).
2. forward the same port for different LAN clients, based on the public ip of the traffic sender
3. forward the whole traffic from specified public ips to one specific LAN ip.

[Alen]

it will be nice, if in Wingate we can make holes and port redirections not only for a specified port, but also specified ip:port or even range of ips:range of ports!

In that case it will be possible to:
1. permit traffic from specified ips:ports only, or just specified public ips (meaning, all traffic from that ips - by setting range of ports = 0-65535).
2. forward the same single port for different LAN clients, based on the source (public) ip
3. forward the whole traffic from specified public ips to one specific LAN ip.

Adrien, I wonder, have you any plans do deploy this in Wingate 7? Or at least, do you think these functionality is quite demanded?

[Alen]

Adrien, what can you say, has Wingate 7 such functionality?

[adrien]

Hi

we've spent a lot of time looking into ways to do such things, going back several years.

However given current time frames, it's not going to make it into WinGate 7.0. It is high on our list of priorities for features for 7.1 though. It requires quite a lot of restructuring in our kernel driver codebase, which has a lot more inherent risks than user-mode code. Due to this risk, and the need to get WinGate 7 out, we decided to defer this feature.

The plan is to have rules either like standard line-based traffic rules where you define source and destination match criteria and then a result (e.g. divert, forward, block etc) or to use a decision tree like WinGate 7 policy.

So WinGate 7 will look and behave the same as WinGate 6 in this respect.

Regards

Adrien

[Alen]

Thank you for the answer.

I think it could be very usefull for users and it also would be one of Wingate advantages in comparison with other products (I believe the described functionality is not widely integrated into existing products, though it is quite demanded for business entities).

Don't put aside it for a long.


P.S. Adrien, still waiting for your answer for KAV update issue (KAV 3 cann't be updated via proxy).