Hi,
I am confused with my comments about point 3) in my previous email. And I not sure if your answer relates to my question.
.
I said: (the complete part is attached at the end)
(Remember that my default policy is deny-all.) then at the FW I need NOT 1 but 2 rules !! , i.e.:
Rule 1) Allow traffic from 10.1.1.5 -port 5000 to 10.1.2.11-port 80
and
Rule 2) Allow traffic from 10.1.2.11-port 80 to 10.1.1.5 -port 5000
Otherwise (with only 1 rule) the FW will filter the traffic in one or other direction.
The main doubt is about
a) "configuring a path downstream" in NATFW specification means "NSIS is downstream but associated traffic can be in any direction over the path"
against
b) "configuring a path downstream" in NATFW specification means "NSIS is downstream AND associated traffic is only in downstream direction over the path too"
I think that your answer
NSIS signaling (and thus the meaning on the NSLP layer) is uni-directional.
is OK in NSIS context, but what I am looking for is to decide if the implementation at 'iptables' level is OK or not.
Example: I connect to a WWW server with my browser. The traffic is
1) MyPC--->WWWserver - I send a TCP SYN packet to the destination, 2) WWWserver <---MyPC - destination sends back SYN+ACK 3) MyPC--->WWWserver - I reply with an ACK.
Note that there is a traffic from/to MyPC to/from WWWserver.
Now suppose that I want to open a firewall using NSIS to allow my connection.
In practice we need 2 entries in IPTABLES
1) One entry to allow MyPC--->WWWserver direction 2) Another entry to allow WWWserver <---MyPC direction
This is because in iptables we configure FROM IP/port TO IP/port. Therefore we need 2 rules.
Example:
MyPC : IP 200.233.16.6 port 4000 WWWserver : IP 200.233.228.9 port 80
rule 1: FROM 200.233.16.6 ( 4000 ) TO 200.233.228.9 ( 80 ) ; SYN case, ACK case rule 2: FROM 200.233.228.9 ( 80 ) TO 200.233.16.6 ( 4000 ) ; SYN+ACK case
So, about this was my question : We need 2 entries in IP tables (traffic that go and that return).
This thread comes about that you are using only one call to iptables, and it is working because you have an allow all policy thus you can not notice any strange.
In my case I have a deny-all policy, so, if I do not add the second entry in iptables I will never receive the SYN+ACK.
Then in createPinhole() (assume an allow-all policy)
For example, I think that you need to add an additional line after
else if (ruleaction == 2){
sprintf(buf, "iptables -A natfwforward -p tcp -s %s/%d --sport %d -d %s/%d --dport %d -j DROP ", saddrbuf, srcPrefix, srcPort, daddrbuf, destPrefix, destPort);
for example something like
sprintf(buf, "iptables -A natfwforward -p tcp -s %s/%d --sport %d -d %s/%d --dport %d -j DROP ", daddrbuf, destPrefix, destPort saddrbuf, srcPrefix, srcPort, );
Note the switch between origin/destination IPs/ports
Regards,
Sergio
(Remember that my default policy is deny-all.) then at the FW I need NOT 1 but 2 rules !! , i.e.:
Rule 1) Allow traffic from 10.1.1.5 -port 5000 to 10.1.2.11-port 80
and
Rule 2) Allow traffic from 10.1.2.11-port 80 to 10.1.1.5 -port 5000
Otherwise (with only 1 rule) the FW will filter the traffic in one or other direction.
Do you agree? Comments?
My question is :
- Should I use 1 time nsis-natfw and open the traffic for both
sides (i.e. 2 calls to Iptables in createPinhole())?
or
- Should I use 2 times nsis-natfw and open the traffic for one
direction per execution?
(I think that the the correct answer is 1, otherwise, how should be the MRI in case 2...)
NSIS signaling (and thus the meaning on the NSLP layer) is uni-directional. Thus you are right, that one signaling session will only open one direction. You will have to initiate NSIS signaling from both sides (!) to open the pin hole if your data is bi-directional. So the correct answer is your case 2 and the MRI is straight forward. A bi-directional flow is just a set of 2 uni-directional flows and so you need 2 NSIS sessions and the corresponding MRIs are just as usual. In your example: You run the NATFW client on 10.1.1.5 with MRI set to (10.1.1.5 -port 5000 to 10.1.2.11-port 80) and you run the NATFW client on 10.1.2.11 with MRI set to (10.1.2.11-port 80 to 10.1.1.5 -port 5000).
Henning: Is this correct for the NATFW NSLP?
Hi,
I am confused with my comments about point 3) in my previous email. And I not sure if your answer relates to my question.
It does.
The main doubt is about
a) "configuring a path downstream" in NATFW specification means "NSIS is downstream but associated traffic can be in any direction over the path"
against
b) "configuring a path downstream" in NATFW specification means "NSIS is downstream AND associated traffic is only in downstream direction over the path too"
I think that your answer
NSIS signaling (and thus the meaning on the NSLP layer) is uni-directional.
is OK in NSIS context, but what I am looking for is to decide if the implementation at 'iptables' level is OK or not.
Example: I connect to a WWW server with my browser. The traffic is
- MyPC--->WWWserver - I send a TCP SYN packet to the destination,
- WWWserver <---MyPC - destination sends back SYN+ACK
- MyPC--->WWWserver - I reply with an ACK.
Note that there is a traffic from/to MyPC to/from WWWserver.
I am fully aware of the situation, but an NSIS signaling session relates to an uni-directional flow. That means: just one direction. So to install FW rules for both directions you will need two NSIS signaling session. Usually this should be done from both sides (from your PC AND from your WebServer in your example). But I am not sure whether there is a special mode in NATFW NSLP which turns the signaling session into bi-directional. If you do not want to initiate NSIS signaling from both sides but both session from your PC (because you have no control over the WebServer), then you should use two NATFW session: one normal CREATE and one which was called UCREATE (Upstream CREATE) in older versions. The new name is REA or EXTERNAL in the latest draft version IIRC.
Henning: Is this correct?
I know that this applies to GIST in general and also to QoS NSLP. In QoS you have a similar problem: You make a VoIP call and voice data is floating in both directions. So if I call the QoS NSLP to reserve bandwidth the reservation will only apply to the data being sent from me to the guy I am talking too. To make a reservation for his traffic too you will need a second NSIS session which originates from the other guy (!).
Regards, Christian
Hi Christian, hi Sergio,
is OK in NSIS context, but what I am looking for is to decide if the implementation at 'iptables' level is OK or not.
Example: I connect to a WWW server with my browser. The traffic is
- MyPC--->WWWserver - I send a TCP SYN packet to the destination,
- WWWserver <---MyPC - destination sends back SYN+ACK
- MyPC--->WWWserver - I reply with an ACK.
Note that there is a traffic from/to MyPC to/from WWWserver.
I am fully aware of the situation, but an NSIS signaling session relates to an uni-directional flow. That means: just one direction. So to install FW rules for both directions you will need two NSIS signaling session. Usually this should be done from both sides (from your PC AND from your WebServer in your example). But I am not sure whether there is a special mode in NATFW NSLP which turns the signaling session into bi-directional. If you do not want to initiate NSIS signaling from both sides but both session from your PC (because you have no control over the WebServer), then you should use two NATFW session: one normal CREATE and one which was called UCREATE (Upstream CREATE) in older versions. The new name is REA or EXTERNAL in the latest draft version IIRC.
Henning: Is this correct?
Yes, that is how I also understand the intention of the draft. Though, in practice we might not have control over this (restricting iptables does not work, or similar)...
Henning
Hi,
1)
If you do not want to initiate NSIS signaling from both sides but both session from your PC (because you have no control over the WebServer), then you should use two NATFW session: one normal CREATE and one which was called UCREATE (Upstream CREATE) in older versions. The new name is REA or EXTERNAL in the latest draft version IIRC.
Ok. It makes sense to use EXTERNAL to establish a reverse path under that point of view. But NSIS reverse path could be different of reverse DATA path over a NSIS path... Let me add some comments. Perhaps the confusion is that a NSIS path is not the same that a DATA path using an established NSIS path?
The specification emphasizes the use of EXTERNAL for a scenarios when there are middle-boxes behind NATs and thus we do not know the destination (private) IP address.
{ draft-ietf-nsis-nslp-natfw-13.txt - 3.7.2. Reserving External Addresses
Data receivers that are only behind firewalls already have a public IP address and they need only to be reachable for NATFW signaling. Unlike data receivers behind just firewalls, data receivers behind NATs do not have public IP addresses; consequently they are not reachable for NATFW signaling by entities outside their addressing realm. }
Then (I understood) the required bindings to reach the NR are established along the path.
Then for FW we have
{ However, in certain scenarios, a node situated behind upstream firewalls that do not block inbound data traffic (firewalls with "default to allow") unless requested might wish to prevent traffic being sent to it from specified addresses. In this case, NSIS NATFW signaling can be used to achieve this by installing a policy rule with its action set to deny using the same mechanisms as for allow rules. }
Here it is not clear if "inbound data traffic" is upstream or downstream.
I understand that the above means that I want to deny upstream traffic when the default policy is allow-all. What it is not clear is: Should be the same for a deny-all FW? i.e. allow upstream traffic.
2)
On the other hand,
{ draft-ietf-nsis-nslp-natfw-13.txt
EXTERNAL (EXT) message: Used to locate upstream NATs/firewalls and prime them to expect downstream signaling and at NATs to preallocate a public address. This is used for data receivers behind these devices to enable their reachability. }
note above in the definition of EXTERNAL :
"prime them to expect downstream signaling"
First, I believe that signaling means NSIS signaling.
Second, "expect downstream signaling" is not equal to what I intend to do 'open a FW for upstream DATA traffic'.
I have the feeling that the purpose of EXTERNAL is only to contribute to the establishment of a NSIS path (establishing bindings and opening FWs that otherwise will make NSIS traffic impossible).
Now, considering the assumption above, a DATA path through FWs and NATs must be created by using CREATE. The NSIS path will be unidirectional , but the DATA path (what can go trough all my NAT bindings and FW allow-rules created by CREATE along the NSIS path) is bidirectional. That is what I understand at this moment.
3)
Anyway, I will review again the specifications so I can narrow my confusion. I do not understand yet how EXTERNAL is triggered (perhaps at GIST level) and also how will be the case for the proxy mode (should the last NF become a NI+ and send EXTERNAL messages?)
Sergio.
Hi Sergio,
In practice we need 2 entries in IPTABLES
- One entry to allow MyPC--->WWWserver direction
- Another entry to allow WWWserver <---MyPC direction
This is because in iptables we configure FROM IP/port TO IP/port. Therefore we need 2 rules.
yes and no. You need to configure iptables with _at least_ one entry. Iptables is a stateful fw, thus it will populate its own tables internally. When configuring iptables with two rules, take care that you remain stateful, otherwise you create a outside->inside rule for connection establishment packets (aka TCP SYN), that's probably not what you want.
Henning
nsis_imp@informatik.uni-goettingen.de
-
Christian Dickmann -
Henning Peters -
sergiole＠tml.hut.fi