This one is going to be hard to explain. First the question and then the
background.
If you have a box bound to two subnets through two NICs, can you code your
socket listener to listen to a particular NIC? I see nothing in the class
that provides this. It currently appears that the listener is, by default,
bound to only one NIC, as it was working prior to moving the machine to be
bound to the gateway on the other subnet.
At this time, I have an alternative SOA solution (which requires a bit too
much coding for my likes), so I am just wondering how to ensure the listener
listens to both subnets (NICs) or how to ground it programmaticall y to one
subnet (NIC). Other solutions are welcome, but that is the primary question.
--------------------------------------------------------------
You can stop reading here if you do not want the background:
--------------------------------------------------------------
On the old network, everything was on a single subnet. This is impossible
now, as we have to set up both a hardware VPN and a software VPN. Due to set
up of the VPNs, or VPN devices (one a Cisco ASA, the other a Linux box), I
cannot set up the software VPN to listen through the hardware device, so we
end up with two gateways. This is the reason for two subnets. It might be
possible to figure out how to get the software VPN through the hardware
device, but it is a vendor solution, which means I am not directly feeding
the person who has to make that change.
The solution worked on a single subnet. The box now sites with NIC one set
up to talk on the subnet with the software VPN machine as its gateway. This
is the "primary NIC" and "primary network". It has a second NIC that sits on
another subnet, where the application server sits. I can move the app server
(web apps only currently) to the other subnet, but this only delays having
to solve this problem, as we will have to work with a VPN on the hardware
device soon and the same applications will have to talk to it. That means
moving the web server to the second subnet is a non-solution for long term.
I can solve this with a SOA solution (web service of some sort: ASMX, WCF),
but all of the web applications will have to change. I then have the web
service talk to the service in the same manner the web applications
currently do. Due to the way the vendor coded his libraries (there is an
unintentional coupling through said libraries), there are a few gotchas in
this approach, but they can be overcome with time.
But if there is a way to tell a listener which network to listen to (which
NIC to listen to), that solves the problem. I am not completely sure
(scientifically ) the listener cannot listen to 2 NICs, but it appears to be
the case. A few days back, when everything was on one subnet (talking to the
hardware VPN), everything worked. It now fails. The only change was
grounding the box with the listener on another subnet.
--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA
Subscribe to my blog
or just read it:
*************** *************** **************
| Think outside the box! |
*************** *************** **************
background.
If you have a box bound to two subnets through two NICs, can you code your
socket listener to listen to a particular NIC? I see nothing in the class
that provides this. It currently appears that the listener is, by default,
bound to only one NIC, as it was working prior to moving the machine to be
bound to the gateway on the other subnet.
At this time, I have an alternative SOA solution (which requires a bit too
much coding for my likes), so I am just wondering how to ensure the listener
listens to both subnets (NICs) or how to ground it programmaticall y to one
subnet (NIC). Other solutions are welcome, but that is the primary question.
--------------------------------------------------------------
You can stop reading here if you do not want the background:
--------------------------------------------------------------
On the old network, everything was on a single subnet. This is impossible
now, as we have to set up both a hardware VPN and a software VPN. Due to set
up of the VPNs, or VPN devices (one a Cisco ASA, the other a Linux box), I
cannot set up the software VPN to listen through the hardware device, so we
end up with two gateways. This is the reason for two subnets. It might be
possible to figure out how to get the software VPN through the hardware
device, but it is a vendor solution, which means I am not directly feeding
the person who has to make that change.
The solution worked on a single subnet. The box now sites with NIC one set
up to talk on the subnet with the software VPN machine as its gateway. This
is the "primary NIC" and "primary network". It has a second NIC that sits on
another subnet, where the application server sits. I can move the app server
(web apps only currently) to the other subnet, but this only delays having
to solve this problem, as we will have to work with a VPN on the hardware
device soon and the same applications will have to talk to it. That means
moving the web server to the second subnet is a non-solution for long term.
I can solve this with a SOA solution (web service of some sort: ASMX, WCF),
but all of the web applications will have to change. I then have the web
service talk to the service in the same manner the web applications
currently do. Due to the way the vendor coded his libraries (there is an
unintentional coupling through said libraries), there are a few gotchas in
this approach, but they can be overcome with time.
But if there is a way to tell a listener which network to listen to (which
NIC to listen to), that solves the problem. I am not completely sure
(scientifically ) the listener cannot listen to 2 NICs, but it appears to be
the case. A few days back, when everything was on one subnet (talking to the
hardware VPN), everything worked. It now fails. The only change was
grounding the box with the listener on another subnet.
--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA
Subscribe to my blog
or just read it:
*************** *************** **************
| Think outside the box! |
*************** *************** **************
Comment