HPE GreenLake Administration
- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - Linux
- >
- to browse through a proxy in different network
Operating System - Linux
1830177
Members
2339
Online
109999
Solutions
Forums
Categories
Company
Local Language
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Go to solution
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-11-2008 04:18 AM
10-11-2008 04:18 AM
hi,
My squid server's (fedora c6) private ip is 172.16.16.125/16. I want to enable automatic virus update on a windows server that has an ip of 10.10.10.2/24.
for this, I configure another server(fedora) with two network card and enabled routing.The ip configured are 10.10.10.51 and 172.16.16.130 with same ip address as gateway. Route -n output is given below
route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.10.10.0 10.10.10.51 255.255.255.0 UG 0 0 0 eth1
10.10.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
172.16.0.0 172.16.16.130 255.255.0.0 UG 0 0 0 eth0
172.16.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
ip_forwarding also enabled on this system.
On proxy, iptables has been enabled and it accept only proxy request from 172.16.16.130 at port no 3128.
At present I can browse from 172.16.16.130/16
(proxy 172.16.16.125)server, but not from 10.10.10.2 server where the proxy is set as 10.10.10.51 . From 10.10.10.2 server I can ping to 172.16.16.130.
Apart from these configurations, what should I do to enable browsing from 10.10.10.0 network?
Kindly help me to solve this issue
Regards,
My squid server's (fedora c6) private ip is 172.16.16.125/16. I want to enable automatic virus update on a windows server that has an ip of 10.10.10.2/24.
for this, I configure another server(fedora) with two network card and enabled routing.The ip configured are 10.10.10.51 and 172.16.16.130 with same ip address as gateway. Route -n output is given below
route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.10.10.0 10.10.10.51 255.255.255.0 UG 0 0 0 eth1
10.10.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
172.16.0.0 172.16.16.130 255.255.0.0 UG 0 0 0 eth0
172.16.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
ip_forwarding also enabled on this system.
On proxy, iptables has been enabled and it accept only proxy request from 172.16.16.130 at port no 3128.
At present I can browse from 172.16.16.130/16
(proxy 172.16.16.125)server, but not from 10.10.10.2 server where the proxy is set as 10.10.10.51 . From 10.10.10.2 server I can ping to 172.16.16.130.
Apart from these configurations, what should I do to enable browsing from 10.10.10.0 network?
Kindly help me to solve this issue
Regards,
Solved! Go to Solution.
3 REPLIES 3
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-12-2008 06:37 AM
10-12-2008 06:37 AM
Solution
Your server with the two NICs is now a router/gateway. It is not a "default gateway", but a more limited gateway. I will refer to it as a "gateway server".
Routing does not hide the original source of the traffic from the destination, unless you do some NAT in addition to the routing.
Problem 1:
You're trying to reach the proxy using address 10.10.10.51. This is the address of the gateway server, not the address of the proxy. If you want to reach the proxy, you should be using the proxy's address - 172.16.16.125.
----
Problem 2:
At this poing, 172.16.16.130 can reach the proxy (172.16.16.125) directly, so it automatically knows what to do.
But the windows server (10.10.10.2) would not automatically know that the 172.16.*.*/16 network is reachable through 10.10.10.51. Have you configured this route to the windows server? (You say you can ping 172.16.16.130, so maybe you have.)
If the windows server has a correct route entry to the 172.16.*.*/16 network, then the windows server knows send the packets to 10.10.10.51.
If you ping 172.16.16.130 from the windows server, that route entry causes the windows server to send the ping packet to 10.10.10.51. When your gateway server receives the packet, it will see that the packet's destination is one of its own addresses, so it will answer to the ping. As your gateway server is directly connected to the 10.10.10.*/24 network, it will send the answer directly back to the windows server.
But, if you try to connect to 172.16.16.125 from the windows server, what will happen?
1.) The windows server will send the packet to 10.10.10.51, the gateway server.
2.) The gateway server sees the packet is addressed to 172.16.16.125, so the server must transfer the packet to the 172.16.*.*/16 network. It will send the packet going towards 172.16.16.125, _without changing_ the source and destination addresses of the packet in any way.
3.) Your squid server (172.16.16.125) receives the packet... but its source address is 10.10.10.2, not 172.16.16.130. The iptables filter will drop the packet.
4.) The windows server will fail to establish a connection to the proxy server.
----Problem 3: How will the squid server know where to send its responses?
When setting up non-default gateways like this, both the squid server and the windows server will need explicit routes telling how to reach the other endpoint network. Otherwise, the requests of the windows server may reach the squid server, but the responses won't be routed back the same way.
This is called _asymmetric routing_: it can be done intentionally in some specific situations, but more often it is a configuration error that will lead to failure.
-----------
Alternative ways to solve your problem:
1.) Remove your gateway server, and instead simply add another NIC to your squid server. Set the new NIC's IP address to 10.10.10.51 and connect it to the 10.10.10.*/24 network segment. _Do not_ enable routing.
Make sure the squid proxy listens on both NICs, and configure 10.10.10.51 as the proxy IP address to your windows server.
This is using your proxy server in the task it is designed for, without any extra complications.
2.) If you cannot add a NIC to the proxy server, talk with your network and/or firewall administrator(s). They might be able to solve your problem with just a little bit of router and/or firewall configuration and one length of network cable (from the Windows network switch to a router or firewall box).
In this case, the windows server will attempt to connect the proxy server through its configured default gateway, but the default gateway is told to pass the traffic to your squid server.
3.) If you absolutely must stick to your original plan, you can use NAT on the gateway server to make it work.
First, the gateway server must be told to pass the traffic coming in to its port 3128 to the proxy, instead of trying to handle it on its own. With this rule, the windows server's routing table does not need to know anything about the 172.16.*.*/16 network.
iptables -t nat -A PREROUTING -s 10.10.10.2 -p tcp --dport 3128 -j DNAT --to-destination 172.16.16.125:3128
Masquerading the forwarded traffic on the gateway server will eliminate the need to change routing tables on the squid server.
iptables -t nat -A POSTROUTING -s 10.10.10.2 -d 172.16.16.125 -j MASQUERADE
Now the incoming traffic will look like it was originated by the gateway server, while it actually comes from the windows server.
To be secure, we must limit the forwarding so that only the traffic from the windows server to the squid proxy is forwarded:
iptables -A FORWARD -s 10.10.10.2 -d 172.16.16.125 -p tcp --dport 3128 -j ACCEPT
Of course, the responses from the proxy server must be allowed to come back:
iptables -A FORWARD -s 172.16.16.125 -m state --state ESTABLISHED,RELATED -j ACCEPT
Anything else must not be forwarded:
iptables -A FORWARD -j DROP
Note: the ordering of the FORWARD rules is important here. The DROP rule must be the last of the three.
----
Whatever you do, make sure you have the authorization to do that. If there is a security policy that says the windows server network must be completely isolated from the Internet, you _must not_ make any connections that break this isolation until this exception is authorized and documented in writing.
Otherwise, you will get blamed if something (anything!) goes wrong...
MK
Routing does not hide the original source of the traffic from the destination, unless you do some NAT in addition to the routing.
Problem 1:
You're trying to reach the proxy using address 10.10.10.51. This is the address of the gateway server, not the address of the proxy. If you want to reach the proxy, you should be using the proxy's address - 172.16.16.125.
----
Problem 2:
At this poing, 172.16.16.130 can reach the proxy (172.16.16.125) directly, so it automatically knows what to do.
But the windows server (10.10.10.2) would not automatically know that the 172.16.*.*/16 network is reachable through 10.10.10.51. Have you configured this route to the windows server? (You say you can ping 172.16.16.130, so maybe you have.)
If the windows server has a correct route entry to the 172.16.*.*/16 network, then the windows server knows send the packets to 10.10.10.51.
If you ping 172.16.16.130 from the windows server, that route entry causes the windows server to send the ping packet to 10.10.10.51. When your gateway server receives the packet, it will see that the packet's destination is one of its own addresses, so it will answer to the ping. As your gateway server is directly connected to the 10.10.10.*/24 network, it will send the answer directly back to the windows server.
But, if you try to connect to 172.16.16.125 from the windows server, what will happen?
1.) The windows server will send the packet to 10.10.10.51, the gateway server.
2.) The gateway server sees the packet is addressed to 172.16.16.125, so the server must transfer the packet to the 172.16.*.*/16 network. It will send the packet going towards 172.16.16.125, _without changing_ the source and destination addresses of the packet in any way.
3.) Your squid server (172.16.16.125) receives the packet... but its source address is 10.10.10.2, not 172.16.16.130. The iptables filter will drop the packet.
4.) The windows server will fail to establish a connection to the proxy server.
----Problem 3: How will the squid server know where to send its responses?
When setting up non-default gateways like this, both the squid server and the windows server will need explicit routes telling how to reach the other endpoint network. Otherwise, the requests of the windows server may reach the squid server, but the responses won't be routed back the same way.
This is called _asymmetric routing_: it can be done intentionally in some specific situations, but more often it is a configuration error that will lead to failure.
-----------
Alternative ways to solve your problem:
1.) Remove your gateway server, and instead simply add another NIC to your squid server. Set the new NIC's IP address to 10.10.10.51 and connect it to the 10.10.10.*/24 network segment. _Do not_ enable routing.
Make sure the squid proxy listens on both NICs, and configure 10.10.10.51 as the proxy IP address to your windows server.
This is using your proxy server in the task it is designed for, without any extra complications.
2.) If you cannot add a NIC to the proxy server, talk with your network and/or firewall administrator(s). They might be able to solve your problem with just a little bit of router and/or firewall configuration and one length of network cable (from the Windows network switch to a router or firewall box).
In this case, the windows server will attempt to connect the proxy server through its configured default gateway, but the default gateway is told to pass the traffic to your squid server.
3.) If you absolutely must stick to your original plan, you can use NAT on the gateway server to make it work.
First, the gateway server must be told to pass the traffic coming in to its port 3128 to the proxy, instead of trying to handle it on its own. With this rule, the windows server's routing table does not need to know anything about the 172.16.*.*/16 network.
iptables -t nat -A PREROUTING -s 10.10.10.2 -p tcp --dport 3128 -j DNAT --to-destination 172.16.16.125:3128
Masquerading the forwarded traffic on the gateway server will eliminate the need to change routing tables on the squid server.
iptables -t nat -A POSTROUTING -s 10.10.10.2 -d 172.16.16.125 -j MASQUERADE
Now the incoming traffic will look like it was originated by the gateway server, while it actually comes from the windows server.
To be secure, we must limit the forwarding so that only the traffic from the windows server to the squid proxy is forwarded:
iptables -A FORWARD -s 10.10.10.2 -d 172.16.16.125 -p tcp --dport 3128 -j ACCEPT
Of course, the responses from the proxy server must be allowed to come back:
iptables -A FORWARD -s 172.16.16.125 -m state --state ESTABLISHED,RELATED -j ACCEPT
Anything else must not be forwarded:
iptables -A FORWARD -j DROP
Note: the ordering of the FORWARD rules is important here. The DROP rule must be the last of the three.
----
Whatever you do, make sure you have the authorization to do that. If there is a security policy that says the windows server network must be completely isolated from the Internet, you _must not_ make any connections that break this isolation until this exception is authorized and documented in writing.
Otherwise, you will get blamed if something (anything!) goes wrong...
MK
MK
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-12-2008 07:30 AM
10-12-2008 07:30 AM
Re: to browse through a proxy in different network
¿Are you keeping your old proxy server also and going through it?
First, ensure that your NEW proxy server, can browse Internet directly. You must allow in your old proxy server to forward packets to Internet to the new proxy server. Set as gateway for your new proxy server your old proxy server. When the new proxy server is able to browse Internet, configure SNAT/MASQUERADE on this host, so all connections from 172.16 . and set the clientes at 172.16 to use 172.16.16.130 as proxy.
First, ensure that your NEW proxy server, can browse Internet directly. You must allow in your old proxy server to forward packets to Internet to the new proxy server. Set as gateway for your new proxy server your old proxy server. When the new proxy server is able to browse Internet, configure SNAT/MASQUERADE on this host, so all connections from 172.16 . and set the clientes at 172.16 to use 172.16.16.130 as proxy.
Por que hacerlo dificil si es posible hacerlo facil? - Why do it the hard way, when you can do it the easy way?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-13-2008 11:14 PM
10-13-2008 11:14 PM
Re: to browse through a proxy in different network
Thank you for the detailed replay.
>3.) If you absolutely must stick to your >original plan, you can use NAT on the gateway >server to make it work.
I prefer the 3rd solution.
As you instructed, I configured nat and forward chain in gateway server. Still I can't browse from 10.10.10.2 windows server.
Proxy server is configured to accept only proxy request from 172.16.16.130
#iptables -A INPUT -s 172.16.16.130 -p tcp -m tcp --dport 3128 -j ACCEPT
Should I need to make any changes to this entry?
If I give 172.16.16.130 as GW for proxy(this entry effected badly on other 172. n/w sytems that uses 130 server as their proxy) and give appropriate entry for 10.10.10.2 server on proxy's iptables, I can ping between 172.16.16.125 and 10.10.10.2. Then I change the proxy servers ip on 10.10.10.2 from 10.10.10.51 to 172.16.16.125.But still I'm not able to connect to the internet.
Regards,
>3.) If you absolutely must stick to your >original plan, you can use NAT on the gateway >server to make it work.
I prefer the 3rd solution.
As you instructed, I configured nat and forward chain in gateway server. Still I can't browse from 10.10.10.2 windows server.
Proxy server is configured to accept only proxy request from 172.16.16.130
#iptables -A INPUT -s 172.16.16.130 -p tcp -m tcp --dport 3128 -j ACCEPT
Should I need to make any changes to this entry?
If I give 172.16.16.130 as GW for proxy(this entry effected badly on other 172. n/w sytems that uses 130 server as their proxy) and give appropriate entry for 10.10.10.2 server on proxy's iptables, I can ping between 172.16.16.125 and 10.10.10.2. Then I change the proxy servers ip on 10.10.10.2 from 10.10.10.51 to 172.16.16.125.But still I'm not able to connect to the internet.
Regards,
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
Company
Events and news
Customer resources
© Copyright 2025 Hewlett Packard Enterprise Development LP