And by IP rule you mean what? This is not a firewall issue. Traffic flows back and forth perfectly. What JNOS should be doing is to respond to packets in the same manner in which they arrived. If they came in via encap they should go out via encap, if they come in directly they should go out directly. Simply adding a default route via the encap interface is not right as it will send all non 44 traffic to ucsd even if I don't want it to go there. I'm sure ucsd could do without the extra traffic too. Mark On Thu, Sep 5, 2013 at 1:15 PM, Michael E. Fox - N6MEF <n6mef(a)mefox.org>wrote;wrote: > (Please trim inclusions from previous messages) > _______________________________________________ > If you want to direct outbound packets from your 44.x addresses back > through > the UCSD gateway, you need to create an ip rule to do so. > > Michael > N6MEF > > -----Original Message----- > From: 44net-bounces+n6mef=mefox.org(a)hamradio.ucsd.edu > [mailto:44net-bounces+n6mef=mefox.org@hamradio.ucsd.edu] On Behalf Of Mark > Phillips > Sent: Thursday, September 05, 2013 10:05 AM > To: AMPRNet working group > Subject: [44net] Routing and encap minor issue in JNOS > > (Please trim inclusions from previous messages) > _______________________________________________ > Hi all, > > Firstly, if this has been done to death before please forgive me. I could > not find anything in the archive. > > Secondly, I have noticed an "issue" with the routing and encap within JNOS. > > It would seem that if a 44 station tries to contact me all works fine. For > example I can communicate with N2NOV and GB7CIP exactly how you would > expect. > > However, if a "public" address contacts me, I get their connect requests in > encap format via uscd but then I send them my response directly rather than > back the same way it came. > > This means that there can be no public access to my system via the > Internet. > > What have I missed? JNOS will not allow me to set the default route via > encap/uscd and I don't really want to send all my traffic (eg DNS lookups) > via there anyway. How can I respond to connections in the same way that I > received them? > > Thinking about it, it makes sense that JNOS replies directly. Once it > unpacks the packet and discovers an encap'd one inside it will work on that > one exclusively. > > Thanks > > Mark >

Hello Mark, You have 2 options... For single ampr IP setups, you can use a 1 rule solution: ip route add default via 169.228.66.251 dev ampr0 onlink table default ip rule add from 44.182.21.1 table default substitute the interface name in the route command and your ampr address in the rule sets. This assumes that the ampr routes are in the table 'main'. If not substitute with your table name. Of course you can use another table instead of default. But this table is already there and usually empty. If you need to forward IP ranges, the easiest way is to use routing marks and a table, again substitute with your values. You can use any numeric value to mark the route... ip route add default via 169.228.66.251 dev ampr0 onlink table default ip rule add fwmark 44 table default iptable -t mangle -A PREROUTING -i ampr0 -p all ! -s 44.0.0.0/8 -d 44.182.20.0/24 -j MARK --set-mark 44 iptable -t mangle -A PREROUTING ! -i ampr0 -p all -s 44.182.20.0/24 ! -d 44.0.0.0/8 -j MARK --set-mark 44 iptable -t mangle -A OUTPUT -p all -s 44.182.20.0/24 ! -d 44.0.0.0/8 -j MARK --set-mark 44 This will mark all traffic from non-ampr addresses via tunnel and all outgoing and forwarded ampr traffic to non-ampr hosts with routing mark 44 and use table default to forward the replies it to the default gw 169.228.66.251 via tunnel. Have fun, Marius, YO2LOJ

Correction as last line should read: can not If you do your encap in jnos you are out of luck as jnos can not handle that specific case. 73. Bob VE3TOK On 13-09-05 03:33 PM, Bob Tenty wrote:

Jnos can't do this presently as it can't do routing based on the "From" address. If you want that to do that you really have to handle all your encap/ipip in linux. Bob VE3TOK On 13-09-05 04:19 PM, Mark Phillips wrote: > (Please trim inclusions from previous messages) > _______________________________________________ > It seems that everyone wants to use iptables in linux. I use JNOS on linux > behind a pfsense firewall. > > The encap packets are forwarded to my JNOS instance properly. > > JNOS can speak to the internet directly via the linux host amd pfsense. > > I only want commercially sourced packets to be responded to via ucsd. > > In other words packets should go put tje same way they came in. > > This should be done in JNOS as it is the target of the packets. > > Question is ; how? > On Sep 5, 2013 3:33 PM, "Bob Tenty" <bobtenty(a)gmail.com> wrote: > >> (Please trim inclusions from previous messages) >> _______________________________________________ >> The traffic from ucsd by ipip is addressed to your 44 address >> and arriving from some Internet address. >> (This is something else as from 44 address to 44 address.) >> Traffic in this case will be routed from your 44 address to an commercial >> Internet address non-encapped over your ISP who blocks traffic from >> 44 addresses. >> This is why you have to tell the linux kernel with rules that if you want >> to >> reach internet FROM your 44 address that you have to route it by ipip >> (encap) >> over ucsd. >> >> Above is if you do your ipip routing with linux. >> If you do your encap in jnos you are out of luck as jnos can handle that >> specific case. >> >> 73, >> >> Bob VE3TOK >> >> >> On 13-09-05 02:42 PM, Mark Phillips wrote: >>> (Please trim inclusions from previous messages) >>> _______________________________________________ >>> And by IP rule you mean what? This is not a firewall issue. Traffic flows >>> back and forth perfectly. >>> >>> What JNOS should be doing is to respond to packets in the same manner in >>> which they arrived. If they came in via encap they should go out via >> encap, >>> if they come in directly they should go out directly. >>> >>> Simply adding a default route via the encap interface is not right as it >>> will send all non 44 traffic to ucsd even if I don't want it to go there. >>> I'm sure ucsd could do without the extra traffic too. >>> >>> Mark >>> >>> >>> On Thu, Sep 5, 2013 at 1:15 PM, Michael E. Fox - N6MEF <n6mef(a)mefox.org >>> wrote: >>> >>>> (Please trim inclusions from previous messages) >>>> _______________________________________________ >>>> If you want to direct outbound packets from your 44.x addresses back >>>> through >>>> the UCSD gateway, you need to create an ip rule to do so. >>>> >>>> Michael >>>> N6MEF >>>> >>>> -----Original Message----- >>>> From: 44net-bounces+n6mef=mefox.org(a)hamradio.ucsd.edu >>>> [mailto:44net-bounces+n6mef=mefox.org@hamradio.ucsd.edu] On Behalf Of >> Mark >>>> Phillips >>>> Sent: Thursday, September 05, 2013 10:05 AM >>>> To: AMPRNet working group >>>> Subject: [44net] Routing and encap minor issue in JNOS >>>> >>>> (Please trim inclusions from previous messages) >>>> _______________________________________________ >>>> Hi all, >>>> >>>> Firstly, if this has been done to death before please forgive me. I >> could >>>> not find anything in the archive. >>>> >>>> Secondly, I have noticed an "issue" with the routing and encap within >> JNOS. >>>> It would seem that if a 44 station tries to contact me all works fine. >> For >>>> example I can communicate with N2NOV and GB7CIP exactly how you would >>>> expect. >>>> >>>> However, if a "public" address contacts me, I get their connect >> requests in >>>> encap format via uscd but then I send them my response directly rather >> than >>>> back the same way it came. >>>> >>>> This means that there can be no public access to my system via the >>>> Internet. >>>> >>>> What have I missed? JNOS will not allow me to set the default route via >>>> encap/uscd and I don't really want to send all my traffic (eg DNS >> lookups) >>>> via there anyway. How can I respond to connections in the same way that >> I >>>> received them? >>>> >>>> Thinking about it, it makes sense that JNOS replies directly. Once it >>>> unpacks the packet and discovers an encap'd one inside it will work on >> that >>>> one exclusively. >>>> >>>> Thanks >>>> >>>> Mark >>>>